Posts made by wergeld

@TRS-80 I looked at Grafana and InfluxDB a few years ago and found them supremely limited. It may be that I am a MS SQL Server user but the act if trying to do an update/delete of a value in InfluxDB is painful. Running everything through a JSON call to modify data annoys me.
So, all that aside I prefer sending data for long term storage to an instance of SQL Server 2012 - even with 4 sensor nodes + weather queries and some other data that send info every 30 seconds, 5 minutes, 10 minutes, and 30 minutes for a few years. I am not even above 100 MB of storage used. The data types are Date, INT, CHAR(xxxx), and in one crazy case VARCHAR(1000). I use Domoticz's built in sqlLite and hassio's DB to handle the data view from my controllers (yes, I have 2). The split of data occurs in Node-Red where it gets the data from my MQTT broker and sends to controllers (different subscription topics due to C/F fubaring in hassio) and send to SQL Server for long term storage. Efficient storage types is the key so a timestamp as an INT/BIGINT would be nice. As long as all your values are INT as well that is even better. Timeseries DBs do have their use, I have just not found one I like.
If there is a timeseries DB that can be accessed via ANSI SQL that would be awesome.

Other thought - you could use Elasticsearch to send in values as "documents" and then run analysis on them. For dataviz, I use the built in ones in my two controllers and I have written my own to handle long term data analysis. I prefer Highcharts for doing the viz as that is what I use at work. It is clean, efficient, and fully customizable.

@pptacek Had not seen those before. Order some and a few nanos to go with it. I had been using the slim node v2 AA battery boards using just the 328p bare chip. Issue I have with that board is the layout of the pins for my needs. It is a great board and I use the nodes I have a lot - no disrespect meant to the developer of it.

I agree that the entry ramp to get mysensors working is a bit complex. I started with the RPi as the gateway because well, it should work. Had a hell of a time making it function. Ended up getting the RPi hat that has the capacitor and NRF slot on it that plugs into the GPIO headers. But, issues persisted with the library for the RPi not working on the RPi 2 until some very helpful folks pointed me in the right direction. A lot of this is pure tinkering and not yet a prime time off the shelf system. I knew that going in and accepted. It has been a great learning experience. The frustration I initially had was all because I expected the guides/docs to be up to date. They are not. As bad as that is, once you accept it and decided to a) add to the docs yourself or b) carry on screaming it becomes rewarding. As an example, getting MySensors to work in Hom Assistant is easy using an MQTT gateway....until you realize that HA tells the nodes what measurment units to use and the nodes then flip (from Celsius to Fahrenheit) when you think it should do the conversion on the front end of HA. I still, for the life of me cannot get the nodes to flip back to Celsius from an MQTT command (had to reflash the nodes with the code).

At the end of all this I am still having fun and learning new things. As the OP said this is not my first programming rodeo (currently a senior SQL developer working with epic sized data with a massive helping of javascript, R, python, and .NET). The micro controller code paradigm was (is still?) new to me even after almost 6 years of messing around with various projects including MySensors.

If we can help any new people stay on this journey it is time well spent. I offer my services for any help that may be needed for docs or guides.

@kalina That is some excellent solder work. Last time i tried to do SMD work it ended up being 110% solder, 5% PCB, and 0% component at the end.

@zboblamont Do you have any more info on this? Components and schematic? I am looking to do this as well as Florida is now fully into storm season.

@nagelc This seems to me the proper way to do it. Presentation of data on web/app should not modify the actual data from the node itself. For now HA is a no go for me until I get a chance to look at the HA mysensors code to see what it is doing.

@gohan I am using node-red in the middle because I have other locations I am sending my sensor data (SQL database, etc). The MySensors MQTT gateway talks on mygateway1-(out/in) and it works great. But, Domoticz requires a different topic as listed here (https://www.domoticz.com/wiki/MySensors#Configuring_the_MQTT-gateway_sketch
For Domoticz to work without additional software (like NodeRED), you will have to set MY_MQTT_PUBLISH_TOPIC_PREFIX to "domoticz/in/MyMQTT" and MY_MQTT_SUBSCRIBE_TOPIC_PREFIX to "domoticz/out/MyMQTT".

Node-red is great for this sort of stuff. I re-broadcast the mygateway1 on the domoticz topic.

I did not add a gateway any differently in HA vs Domoticz - I pointed it at the MQTT topic (in HAs case it is the mygateway1 and for Domoticz it is domoticz). HA happens to send back to the gateway (on an MQTT topic I imagine) the setting to change to imperial from metric (which is the default). But, Domoticz did not do this. I think maybe Domoticz gets the metric/imperial setting from the gateway and then, depending on the Domoticz units configuration, converts the value to be shown on the front end. I suppose the next thing for me to try is just use MQTT on HA without setting up the mysensors gateway explicitly. But, not sure how HA would know to convert my values to imperial. Or, I could just re-code my nodes/gateway to force imperial at all times.

So, first here is my general setup:
Multiple DS18B20 temp sensors sending data in metric.
One ESP8266 gateway that is using the MQTT protocol.
A mosquitto broker running on an RPi
Node-red running on the same RPi that re-broadcasts the MySensors topics (mygateway1-out/blah) on the Domoticz required one (domoticz/in/MyQTT/blah).
The same RPi with latest 4.97 Domoticz install listening on their MQTT topics. Domoticz is set to use imperial units of measure.
All is working as it should.

Last night I installed HomeAssistant (not HASS.io) on my laptop and set it up to use the MySensors protocol and to listen in on the mygateway1-out/# topics. And, of course, I set the HA temp units to imperial. Messed around a bit and decided that enough was done for the night (could not get it to talk to my smart TV).

I then checked my Domoticz dashboard and saw that, well, my house was turning into an oven! The 2 sensor nodes are now reporting temps of 170F! I look at the Domoticz log and it isn't a transient event. I then look at node-red in debug and see that the mygateway1-out is sending out F values instead of C values and Domoticz is converting the values from C to F...but the numbers are already F - so, yay, I get massive wonkiness!

I go back into HA (fire it up again) and change the units system from imperial to metric and, next sensor report cycle, the values are back to being sent in as C. What the ever loving hell? Let's dig into the code a bit.

In the nodes there is this bit:

// Fetch and round temperature to one decimal
   float temperature = static_cast<float>(static_cast<int>((getControllerConfig().isMetric?sensors.getTempCByIndex(i):sensors.getTempFByIndex(i)) * 10.)) / 10.;

Okay, so it asks the controller what it should report in.

• But, why did this change with the HA settings change?

• If HA was just listening on the MQTT topic what the hell is it doing communicating back to the node to tell it use imperial? Can I turn this off and have HA report the correct value (in C) and unit (convert to F)?

• If Domoticz is just listening on the the MQTT topic why is it not telling the gateway to use imperial?

I am very confused by this. If I decide to have my nodes report in F how the hell is Domoticz going to handle that? Do I then have to change Domoticz settings to C to get the real number but have incorrect units assigned?

I really don't think the HA settings - unit change should have any impact whatsoever on the actual number sent from a node. It is purely presentation layer not data layer. There should be a method to tell HA that "values sent are in metric" and if the front end unit is set to imperial it should convert the raw number on HA's side - not change the settings on the gateway.

@stkilda It really depends on how much "control" you want. I run mosquitto broker, node-red (for handling lots of MQTT messages and for internet API calls), and for my controller I use Domoticz. All of this on my raspberry pi 2 B. I have around 1% CPU usage and ~25% RAM usage. There is not a lot of cross-traffic on my system (meaning I only send data to Domoticz from nodes and not the other way around). This works just fine. You can do the same on your laptop given any OS you want to use - your install and config will of course be different. Yes, you need to have your controller on all the time.

Domoticz is the easiest to get up and running. All you need is an ethernet/serial gateway and off you go. I use the MQTT gateway and Domoticz requires its own MQTT topic (lame) but that is easy to setup on node-red (I just rebroadcast my MQTT gateway messages on a the Domoticz topic).

@chisight I had done the raw file import. Issue I was facing was with the single/double quotes being interchanged. Easy fix. I am not sure if my "fix" for the VString was necessary. I just wanted to see what each sensor value was going to return. I need to get my DB setup a little better (using SQL Server as I cant stand the rigidness of time-series DBs like Influx).

A little clean up in notepad++ and I have a working flow!
I made some modifcations (of course) for my setup. The main one is the ability to get the sensor value type. Initially the code in the Parse node did:

// msg.topic = context.global.MYS.TOPIC_PREFIX + '/' + msg.controller + ' / ' + msg.nodeId + ' / ' + msg.childSensorId + ' / ' + msg.subTypeString;


 var tokens = msg.topic.split('/');
 
 msg.rawData = tokens;
 if(tokens.length >= 5)
 {
 msg.controller = parseInt(tokens[1]);
 msg.nodeId = parseInt(tokens[2]);
 msg.childSensorId = parseInt(tokens[3]);
 msg.subTypeString = tokens[4];
 msg.subType = context.global.MYS.VNum(msg.subTypeString);
 msg.command = 1; // SET
 msg.acknowledge = 0; // no ack as default
 }

return msg;

I modified the msg.subType to use:

msg.subType = context.global.MYS.VString(msg.subTypeString);

Now to set this up to write to my DB.
Many thanks to @FotoFieber and @chisight

@chisight I attempted to use this code but node-red would not let me import. Checked the json online and it does not appear to be valid.

Christmas wreathe for the techie in all of us.
pretty colors
flashing
wire wrapping

Uses a pro mini and a lot of wire-wrapping. Other components on the circuit boards are just there for show.

(ugh, google photos links not showing up so converted to links)

So, got my ESP8266 and set it up as the ethernet gateway. Removed the on-board RPi gateway. Domoticz picked up the new gateway easily enough (this has never been an issue). Now, turned on my nodes (with static nodeIDs) and the gateway picked up one of the two nodes (why? no idea). Sent presentation to gateway then to Domoticz. Domoticz sees the humidity sensor as S_UNKNOWN but with V_HUM values???? I have no idea what is happening. The ESP gateway log shows the sensor as S_HUMIDITY just fine. So, this is a new wrinkle. But the same issue persists - temp/hum updated on the Hardware view of the gateway but Device view of that sensor is never updated from initial state. I am this close to taking the whole system out back with a baseball bat.

So, status now:
Only 1 of 2 nodes seen by gateway (unique IDs on both)
The 1 node values are sent to gateway around every 5 minutes (with new values as tested over night)
Domoticz does not update the Device with any new values from initially seen data
Gateway serial log is showing updates just fine
MYScontroler running on my Windows box also sees the updates just fine
OpenHab2 does not see any updated from initially seen data
Stress level at 100%

So, since updating to beta release on 11/2 it has now been 5 days since the Device value has been refreshed. Every time I go to check the Hardware view it is updated and has new/diff values. This is stupid.
I have now updated to the latest Domoticz beta in hopes something changes.

@sundberg84 No, it is a different value. In my image above you see that the Hardware shows 15.6C (which is 60F) and the Device shows 72F. When I view the log for the gateway I see that roughly every 5 minutes (which is what I set in the node as minimum send rate) there are new values - and they match in Hardware view of the node. My view of the Devices is for All devices. The only one under Not Used is that "new" Temp only item.

@sundberg84 Okay, but why would it not report updated values for Temp then when Hardware view of the node shows updates?

@sundberg84 Not sure I follow but will try and answer each item.
If you look around you might find one added device with combined Temp/Hum and two single devices 1) Temp 2)Hum
I only see these two devices listed. The Temp+Humidity was created before the upgrade to 3.8666 and was last updated at ~4:30pm yesterday (although the Hardware view of the nodes showed updated (and different) values up until my upgrade of Domoticz. The other device is Temp only and was last updated (actually the first time seen) at ~9pm yesterday and not updated since. No other combined devices from MySensors nodes present (there are others from Weather Underground).

This is because Domoticz wants to incorporate two devices (HUM + Temp) into one. If the values are presented in a certain order they are combined into a single node. If the node does not update regular they will be read as two different devices and not updated on the first one.
Again, the node does update regularly (about every 5 minutes if a value has changed). Look at the Hardware view - it shows that both temp/hum were updated at 7:11am this morning but Device view says only temp was updated at 9pm last night or combined temp/hum at 4:30 yesterday.

To avoid this I use two options. Present the temp/hum/(baro) as child ids not close to each other (1-2 and 2-3) or you have to update all values in the same time (ie. you cant use, if value is the same do not send it).
I will look into how to present two different child IDs.
The values are updated at different intervals from node. In the code on the node I test if new measurement for temp is different than last measurement - if so I send, if not I don't. Same for humidity. I can alter this to send temp/hum value if either one is different.

Well,
I let the system run over night after upgrading to latest beta 3.8666. And same (yet slightly different issue) persists. The node is updated in the Hardware view but the Device view has not had the temp/hum updated - AND there is now a new device but it is only for temp????
Hardware:

Observe that data was last seen minutes ago.

Device:

Note the "LaCrosse TX3" entry that only reports temp - this is new. I am at a complete loss here.

@gohan Okay, flipping over to beta channel.

@gohan Yes, did that. Same thing. Node reports data to Domoticz. Domoticz shows the updated values in Hardware view but does not update the device. I have tried auto-ID assignment and manual using different IDs. Same result each time.

MySensors ethernet gateway on rPi direct connection using 2.2.0-beta
Node with temp/hum sensor using 2.2.0-beta
Domoticz 3.8153

I have added the gateway and it is "seen" by Domoticz. I added the node and it is seen in the Hardware view. After several days the node finally showed up under Devices (even when setting Domoticz to accept new devices and turning on the node in that time).
For hours at a time the Hardware view of the node shows updated data but the Device view (and consequently the dashboard item) shows no updated data. The values are different than the last value in Devices.

Hardware view:

Device view:

What do I have to do to get Domoticz to use the updated values? This has been going on for a week+ now. No response on Domoticz forum for this issue.

@mfalkvidd said in NRF24L01+ problems in 2.1.1 and 2.2.0 Beta:

git checkout 4c31e22d6ff45c3a4f8aa70f915c5f10fe345f64

Okay, this works for me now as well. However, Domoticz still doesn't report any updated data beyond the first seen measurement for the temp portion of the sensors....I am about to see how far these slim nodes can fly...

@gohan Yea, I have one on order taking the slow boat from China. But, it bothers me that MYSControler "gets" the sensor node values and the other controlers do not. Same IP config. And the weird NACK errors. Something just seems screwy as this hardware was working up until about 3 months ago - no changes made.

@gohan unable to run my node in debug with radio attached at the moment (no 3.3v FTDI or mosfets available right now).
But, that being said - the MYSControler does get the updated values. Just not Domoticz or OpenHab. So, why does one client connecting to the gateway get data while the other two do not?

@gohan Yes, capacitors on both the node(s) and the gateway radios. Moving the nodes closer to gateway has no affect. The gateway is sending out udpates (per MYSControler at least) but Domoticz sees no new devices and OpenHab has not seen an update either. So frustrating.

@gohan This doesnt really make sense to me. This happens after I get data from a sensor and the gateway gets stuck in a loop of those messages. MYSControler shows the correct value that triggered these messages while OpenHab and Domoticz do not.

This is getting odder and odder.
I am running 2.2.1 beta on my RPi2B. It is running on channel 76, with power max, and using ethernet gateway config.
I have MYSController running on separate laptop and it is seeing updates to temp/hum and/or battery level. However, neither Domoticz or OpenHab2 have seen a change since last night at 9pm.

In Domoticz - Setup - Hardware - Mysensors 2.2.0 Gateway it shows 2 nodes. First node is the gateway, of course, and the second is the sensor node. The data and the last seen times are correct! But, the Domoticz - Setup - Device list only shows the Temp sesnor and a last seen date of last night at 9pm. There are not other mysensors devices available.
So, what is different between MYSControler and Domoticz and OpenHab?

So, I did a lot of re-configuring and using 2.2.0 beta when a node sends a value payload (in my case a temp/humidity/battery value I get this while running my RPi ethernet gateway in debug:

mysgw: TSF:MSG:READ,3-3-255,s=255,c=3,t=7,pt=0,l=0,sg=0:
mysgw: TSF:MSG:BC
mysgw: TSF:MSG:FPAR REQ,ID=3
mysgw: TSF:CKU:OK,FCTRL
mysgw: TSF:MSG:GWL OK
mysgw: !TSF:MSG:SEND,0-0-3-3,s=255,c=3,t=8,pt=1,l=1,sg=0,ft=0,st=NACK:0
mysgw: TSF:MSG:READ,3-3-255,s=255,c=3,t=7,pt=0,l=0,sg=0:
mysgw: TSF:MSG:BC
mysgw: TSF:MSG:FPAR REQ,ID=3
mysgw: TSF:CKU:OK,FCTRL
mysgw: TSF:MSG:GWL OK

This continues until I kill the process. In the middle of all of these error messages though, it also reports client PING events:

mysgw: Client 0: 0;0;3;0;18;PING

Other interesting items of note:
Domoticz says the values for temp have not been updated for 3+ hours for that node.
Domoticz says that node only has a temp sensor.
MYSController reports it having 2 sensors (temp and humidity) and it reports the values when i would expect them to be sent (ie, not 3+ hours old but updated continuously when temp changes).

I am at my wits end here.

@gohan, I can only speak for me but I have done the following on my RPi 2 B:
Changed out radios
Used shield for radio or just straight wiring to radio
New flash of latest minimal Raspbian
Enabled SPI

And various combinations of those. Maybe something broke in an update to Raspbian or some other change to the mysensors repo?

@gohan That bug had to do with the chipset but that was resolved i think.

@miljume I am having the same issue since 2.1 and trying to revert to 2.2 beta it fails as well. I am using an RPi model 2 B and the same RPI shield (I have traded out the shield as I have a few and same result). All of my nodes have been offline for months as the gateway does not function.

@m26872
UPDATE 2: There have been reported issues with MySensors 2.x freezing on SlimNodes running at 1MHz, which I've confirmed. Recommended solution when using MyS 2.x, is to use 8MHz (internal) instead.

This I can confirm - running at 1 MHz introduced some real oddities with latest MySensors library. Not sure what changed but my nodes definitely freaked out. Will try switching to 8 MHz - hopefully before Irma whacks us here.

@tbowmo I feel I have a lot of reading to do...
Setting up my own custom dashboard has been on my todo list forever (I have the shell made and used the Domoticz API to pull in data but am not really satisfied at all with Domo's APIs). InfluxDB is neat but so, so, limited in my opinion (I do SQL Server big data analytics in the real world).

@tbowmo Do you have a link to your node-red setup? I would like to filter the output of my sensor nodes as well (got a flaky one that sends -47.5 F temp every once in a while.

Found your github!
For others looking it is here.

@kany Well, the data is in a SQLite database for domoticz already. You can move to InfluxDB easily. See this post on the Domoticz forum - this is how I set it up using these instructions.
My qualms with InfluxDB is that deleting a value is nearly impossible.

I have a slim AA node that holds an HTU21D temp/hum sensor (based on this example). This thing has been going strong for about 10 months. Then in the past few days it sends a reading of:
temp = -47.5 F
hum = 25%

Nothing was changed on the node (was not moved/dropped/etc). I went and turned it off via the switch on the battery holder and turned it back on. It worked for a while and then gets stuck in the -47.6/25 data mode. I have checked the voltage on the batteries and there is still plenty left. But, out of due diligence I replaced the batteries with fresh ones. It worked for about 20 transmissions and then... -47.5/25 constantly.
Quick visual inspection of the node shows no abnormalities. Is this a symptom of the HTU21D going "bad" or my arduino chip getting fried somehow?

@Velo17 Thank you! I had been pulling my hair out over this issue on installing a new RPi2 setup.

@Sweetpants Oh, I am not. Just saying that the issues I am having with logging do not have to do with Domoticz.

@NeverDie
Yes, I do have it on a UPS. What I meant is that if I power down the PI. I think the SD cards is toast on it. Nothing seems to be saved to disk - I made a cron job and saved it. But, after a reboot of the Pi the cron job was no longer there. Oh well.

I have stated to mess with dashticz - looks promising but not ready for prime time. Documentation is thin, to say the least. Also, the config switch to use F instead of C works for the numeric value shown - but the suffix is still "C". Also, the culture set is using (for the US, anyway) the wrong thousands separator and decimal point characters. I can add in my Google Maps API key in the locations in the config (with my lat/lon) but it does not appear to "do" anything and I see nothing in the docs on what block or section I need to create to show the maps.

Still, I do like Domoticz.

I have used Domoticz for about 2+ years. I like it a lot but wish for something...more.
Pros:
Quick setup for mysensors nodes
One-stop location for data storage and data presentation
Android app is very good
Customizable scripting options once you leave their scripting environment and use API values.

Cons:
Event scripting (lua? really?) needs more advanced features.
Has interesting issue lately where if I lose power to the Pi I lose all data back to May 23 of this year. I have a cron job that backs up the DB nightly and send to my NAS so I can lose hours instead of days. But, man, is this annoying - I have not tracked down the reason yet.
Graphs are just sort of...there. I do data viz at my job and use Highcharts (Domoticz' charting library) daily. The charts in Domoticz need a lot of work.

I have started writing my own front end that calls data from the Domoticz API (as well as other APIs) for showing info in our house. Nothing crazy cool, but it will eventually work fine for me.

Which brings me to the point - there is no perfect controller. You need to find the one that is right for you.

@bjacobse Yes, I am checking the values and if the same as last transmission I abort and go back to sleep. If, however, it has been 3 hours since last transmission I force it to send.

@m26872 I have looked at a lot of those links. I am leaning towards covering my node in non-reactive glue. This will seal all contacts. The only part that would be difficult would be the actual teeny tiny sensor chip on the HTU21D. Hopefully any condensation there can be minimal. The next step would be to make sure the battery case is sealed as well (although I do not think this will be much of an issue).

@m26872 & @bjacobse - Yes, 100% humidity is normal here. Good old Florida! My concern is that the node stops reporting. Possibly due to condensation shorting out something. During the summer here we also hit 100% humidity but it is also a lot hotter (high 90s). Now, I think that the cooler temps are forcing a dew point that is allowing water to condense on the node. Then during the morning it drys out and resumes transmitting. I would like to find a way to stop this.

So, after a few months of 2 nodes up and running using the HTU21D sensor I have come the conclusion that the HTU21D is no good for where I live. Lately it has been getting cooler outside (down to mid 50s F) but humidity is still high. As the evening progresses the humidity gets to 100% and the node no longer sends data. This happens around 6pm every day (about half and hour after sunset). It then comes back online at about 10 am the next day. The node that I have inside does not have this issue (same shipment of arduino, pcb, and HTU21D sensors and the same arduino code). Both running off of fresh AAs. May need to upgrade to the SI7021 for outside node.

Here is the graph showing last 7 days. As you can see it flatlines (literally!) at 100% humidity!

All good times with the learning!

@wergeld said:

@marceloaqno said:

@wergeld I updated the building instructions:
https://forum.mysensors.org/topic/2759/mysensors-raspberry-port-suggestions/26

Success! Upgraded to Jessie and build worked fine. Now to reconnect my radio to the RPi pins directly to test.

Okay, using an RPi2B upgraded to Jessie from Wheezy I have successfully built and set the mysGateway as a daemon. My configuration was:

./configure --my-gateway=serial --my-serial-is-pty --my-serial-pty=/dev/ttyUSBMySensorsGateway --my-rf24-pa-level=RF24_PA_LOW

This was immediately available in Domoticz under Hardware. I re-added the 2 nodes and away I went!

Full command list:

git clone https://github.com/marceloaqno/MySensors.git
cd MySensors
./configure --my-gateway=serial --my-serial-is-pty --my-serial-pty=/dev/ttyUSBMySensorsGateway --my-rf24-pa-level=RF24_PA_LOW
make
sudo make install
sudo mysGateway -b

In Domoticz it lists this gateway as running:
MySensors Gateway USB
Version: 2.0.1-beta

So far very happy with this setup. No wires and no extra arduino needed for serial gateway. Just the NRF+RPi interfacing via:
https://www.openhardware.io/view/100/Raspberry-PI-NRF24l01-hat

@marceloaqno said:

@wergeld I updated the building instructions:
https://forum.mysensors.org/topic/2759/mysensors-raspberry-port-suggestions/26

Success! Upgraded to Jessie and build worked fine. Now to reconnect my radio to the RPi pins directly to test.

@marceloaqno said:

@wergeld I'm not sure why you are having this error, perhaps your version of gcc it's old? Did you try to update it?
You can skip the installation of TMRh20/RF24, it is no longer necessary to build RPi port.

I have tried to update gcc but apt-get says it is already at latest version. I am upgrading to Jessie now as it has gcc 4.9 (I was running Wheezy with gcc 4.6).
Is there an updated build instruction set? I am planning on using this as a serial gateway with Domoticz on same RPi.

@marceloaqno I have been trying to build this out by first building the RF24 library using the following:

git clone https://github.com/TMRh20/RF24.git
cd RF24
make
sudo make install

However, this fails on the make command:

Makefile:17: Makefile.inc: No such file or directory
[Running configure]
[SECTION] Detecting arm compilation environment.
  [OK] arm-linux-gnueabihf-gcc detected.
  [OK] arm-linux-gnueabihf-g++ detected.
[SECTION] Detecting target machine.
[OK] machine detected: SoC=BCM2836, Type=RPi2, CPU=armv7l.
[SECTION] Detecting DRIVER
  [OK] DRIVER detected:RPi.
[SECTION] Detecting OS.
  [INFO] OS detected:LINUX.
[SECTION] Preparing configuration.
[SECTION] Saving configuration.
[OK] Finished.
arm-linux-gnueabihf-g++ -fPIC -march=armv7-a -mtune=cortex-a7 -mfpu=neon-vfpv4 -mfloat-abi=hard -Ofast -Wall -pthread  -c RF24.cpp
cc1plus: error: bad value (cortex-a7) for -mtune switch
Makefile:40: recipe for target 'RF24.o' failed
make: *** [RF24.o] Error 1

I am not sure what to do here. Looks like the gcc does not support the cortex-a7? I am trying to run this on my RPi 2 B.

@GertSanders Excellent! I was hoping I hadn't wired it up wrong. So far the 2 nodes have been flawless for the past 3 days. Next step is to await the direct attached NRF serial gateway to be v2 compatible. Been following along with this thread. Looks like we are getting closer! I have 2 RPis (one a first gen B and the other a Pi2 B ) with this adapter by ceech:
https://www.openhardware.io/view/100/Raspberry-PI-NRF24l01-hat

I am seeing 5.0 μA at sleep and 12.4 mA when transmitting. Seems kind of high. I did the poor man's test as well - put an LED across the HTU21D power pins and it lit up. Same when I did it across the nrf's power pins. Shouldn't the MySensors code turn off the power rails during sleep?

I have been working on this idea as well. My issue was finding probes that would survive the higher temps and run off a minimal power supply (batteries) - while still being cheap. It is the last item that has prevented me from moving forward. At the prices I have seen for temp probe/IC it is actually cheaper just to get a store bought meat thermometer with a remote display that is locked in. I suppose one could figure out their transmission protocol and port it to some radio receiver to an arduino. I have not even looked at making the grill react to inputs yet but I like that idea.

@TheoL No damage. Water went up about 7 feet on our lake but had another 11 feet to go to threaten our property. Biggest flooding was to the south of us. We did have a fun time hiding out in our laundry room during tornado flying up to the east of us. Also, I do not think the radio is dead - hooked it by accident to my Uno testing board and it was transmitting just fine. Love these things - very tough.

@m26872
Indeed it does. Just was throwing me off with the wording. I read it as "1/2 hour" or "1/3 hour". So far I am prepping up more nodes. Have 4 more 328s to programs and build out. I am thinking at the end I will have:

1. Gateway (serial or the direct connect nrf+ once it supports v2)
2. Temp/Hum node using HTU21D for back porch sending every 5 minutes and force send every 30 minutes.
3. Temp/Hum node using HTU21D inside using same send times.
4. Parking sensor in garage hardwired to mains.
   5 & 6 I am not sure yet.

Lots of fun so far.

Okay, seeing something odd. The force transmit does not appear to be working.
Here is my current sketch:

#define MY_RADIO_NRF24

#include <MyConfig.h>
#include <MySensors.h>

/* Sketch with Si7021 and battery monitoring.
by m26872, 20151109 
*/
//#include <MySensors.h>  
#include <Wire.h>
#include <SparkFunHTU21D.h>
#include <SPI.h>
#include <RunningAverage.h>

//#define DEBUG

#ifdef DEBUG
#define DEBUG_SERIAL(x) Serial.begin(x)
#define DEBUG_PRINT(x) Serial.print(x)
#define DEBUG_PRINTLN(x) Serial.println(x)
#else
#define DEBUG_SERIAL(x)
#define DEBUG_PRINT(x) 
#define DEBUG_PRINTLN(x) 
#endif

#define NODE_ID 132             // <<<<<<<<<<<<<<<<<<<<<<<<<<<   Enter Node_ID
#define CHILD_ID_TEMP 0
#define CHILD_ID_HUM 1
// #define SLEEP_TIME 15000 // 15s for DEBUG
#define SLEEP_TIME 300000   // 5 min
#define FORCE_TRANSMIT_CYCLE 36  // 5min*12=1/hour, 5min*36=1/3hour 
#define BATTERY_REPORT_CYCLE 2880   // Once per 5min   =>   12*24*7 = 2016 (one report/week)
#define VMIN 1900
#define VMAX 3300
#define HUMI_TRANSMIT_THRESHOLD 3.0  // THRESHOLD tells how much the value should have changed since last time it was transmitted.
#define TEMP_TRANSMIT_THRESHOLD 0.5
#define AVERAGES 2

int batteryReportCounter = BATTERY_REPORT_CYCLE - 1;  // to make it report the first time.
int measureCount = 0;
float lastTemperature = -100;
int lastHumidity = -100;

RunningAverage raHum(AVERAGES);
HTU21D humiditySensor;

//MySensor gw;
MyMessage msgTemp(CHILD_ID_TEMP,V_TEMP); // Initialize temperature message
MyMessage msgHum(CHILD_ID_HUM,V_HUM);

void presentation()  
{ 
  sendSketchInfo("HTU21D", "1.0"); 
  present(CHILD_ID_TEMP, S_TEMP);   // Present sensor to controller
  present(CHILD_ID_HUM, S_HUM);
}

void setup() {
  DEBUG_SERIAL(9600);    // <<<<<<<<<<<<<<<<<<<<<<<<<< Note BAUD_RATE in MySensors.h
  DEBUG_PRINTLN("Serial started");
  
  DEBUG_PRINT("Voltage: ");
  DEBUG_PRINT(readVcc()); 
  DEBUG_PRINTLN(" mV");
/*
  delay(500);
  DEBUG_PRINT("Internal temp: ");
  DEBUG_PRINT(GetInternalTemp()); // Probably not calibrated. Just to print something.
  DEBUG_PRINTLN(" *C");
*/  
  delay(500); // Allow time for radio if power useed as reset
  //gw.begin(NULL,NODE_ID);
  //sendSketchInfo("HTU21D", "1.0"); 
  //present(CHILD_ID_TEMP, S_TEMP);   // Present sensor to controller
  //present(CHILD_ID_HUM, S_HUM);
  DEBUG_PRINT("Node and "); DEBUG_PRINTLN("2 children presented.");
  
  raHum.clear();
  
}

void loop() { 

  measureCount ++;
  batteryReportCounter ++;
  bool forceTransmit = false;
  
  if (measureCount > FORCE_TRANSMIT_CYCLE) {
    forceTransmit = true; 
  }
  sendTempHumidityMeasurements(forceTransmit);
/*
  // Read and print internal temp
  float temperature0 = static_cast<float>(static_cast<int>((GetInternalTemp()+0.5) * 10.)) / 10.;
  DEBUG_PRINT("Internal Temp: "); DEBUG_PRINT(temperature0); DEBUG_PRINTLN(" *C");        
*/
  // Check battery
  if (batteryReportCounter >= BATTERY_REPORT_CYCLE) {
    long batteryVolt = readVcc();
    DEBUG_PRINT("Battery voltage: "); DEBUG_PRINT(batteryVolt); DEBUG_PRINTLN(" mV");
    uint8_t batteryPcnt = constrain(map(batteryVolt,VMIN,VMAX,0,100),0,255);   
    DEBUG_PRINT("Battery percent: "); DEBUG_PRINT(batteryPcnt); DEBUG_PRINTLN(" %");
    sendBatteryLevel(batteryPcnt);
    batteryReportCounter = 0;
  }
  
  sleep(SLEEP_TIME);
}

// function for reading Vcc by reading 1.1V reference against AVcc. Based from http://provideyourown.com/2012/secret-arduino-voltmeter-measure-battery-voltage/
// To calibrate reading replace 1125300L with scale_constant = internal1.1Ref * 1023 * 1000, where internal1.1Ref = 1.1 * Vcc1 (per voltmeter) / Vcc2 (per readVcc() function) 
long readVcc() {
  // set the reference to Vcc and the measurement to the internal 1.1V reference
  ADMUX = _BV(REFS0) | _BV(MUX3) | _BV(MUX2) | _BV(MUX1);
  delay(2); // Wait for Vref to settle
  ADCSRA |= _BV(ADSC); // Start conversion
  while (bit_is_set(ADCSRA,ADSC)); // measuring
  uint8_t low  = ADCL; // must read ADCL first - it then locks ADCH  
  uint8_t high = ADCH; // unlocks both
  long result = (high<<8) | low;
  result = 1125300L / result; // Calculate Vcc (in mV); 1125300 = 1.1*1023*1000
  return result; // Vcc in millivolts
}
// function for reading internal temp. From http://playground.arduino.cc/Main/InternalTemperatureSensor 
double GetInternalTemp(void) {  // (Both double and float are 4 byte in most arduino implementation)
  unsigned int wADC;
  double t;
  // The internal temperature has to be used with the internal reference of 1.1V. Channel 8 can not be selected with the analogRead function yet.
  ADMUX = (_BV(REFS1) | _BV(REFS0) | _BV(MUX3));   // Set the internal reference and mux.
  ADCSRA |= _BV(ADEN);  // enable the ADC
  delay(20);            // wait for voltages to become stable.
  ADCSRA |= _BV(ADSC);  // Start the ADC
  while (bit_is_set(ADCSRA,ADSC));   // Detect end-of-conversion
  wADC = ADCW;   // Reading register "ADCW" takes care of how to read ADCL and ADCH.
  t = (wADC - 88.0 ) / 1.0;   // The default offset is 324.31.
  return (t);   // The returned temperature in degrees Celcius.
}

/*********************************************
 * * Sends temperature and humidity from Si7021 sensor
 * Parameters
 * - force : Forces transmission of a value (even if it's the same as previous measurement)
 *********************************************/
void sendTempHumidityMeasurements(bool force) {
  bool tx = force;
  
  float temperature = humiditySensor.readTemperature();
  DEBUG_PRINT("T: ");DEBUG_PRINTLN(temperature);

  float diffTemp = abs(lastTemperature - temperature);
  DEBUG_PRINT(F("TempDiff :"));DEBUG_PRINTLN(diffTemp);

  if (diffTemp > TEMP_TRANSMIT_THRESHOLD || tx) {
    send(msgTemp.set(temperature,1));
    lastTemperature = temperature;
    measureCount = 0;
    DEBUG_PRINTLN("T sent!");
  }
  
  int humidity = humiditySensor.readHumidity();
  DEBUG_PRINT("H: ");DEBUG_PRINTLN(humidity);

  raHum.addValue(humidity);
  humidity = raHum.getAverage();  // MA sample imply reasonable fast sample frequency
  float diffHum = abs(lastHumidity - humidity);
  DEBUG_PRINT(F("HumDiff  :"));DEBUG_PRINTLN(diffHum); 

  if (diffHum > HUMI_TRANSMIT_THRESHOLD || tx) {
    send(msgHum.set(humidity));
    lastHumidity = humidity;
    measureCount = 0;
    DEBUG_PRINTLN("H sent!");
  }
}

I am at 1+ hours since last transmission.

@TheoL
Yea, I was just in a rush to get data! Storm is up in Georgia but is still trying to kick down our area.

Always shield your electronics from the elements. Hurricane Hermine took out its vengeance on my radio.

I had just built this node and was excited to watch the data come in during the hurricane - I did not put into case. Note to self: always put it in a case.

EDIT: Just noticed that my google photos link does not appear to show for me. Not sure if it shows for others. Let me know. Trying plain URL:
https://goo.gl/photos/gELNmGjY5Dk6q7Rj7

After soldering the 3 pads on the HTU21D I am now reading data and it is being sent to my test serial gateway. Need to measure current usage but at least it is functional.

@korttoma
Success! Got this ethernet gateway up and running! Thank you very much.

Okay, I now have a soldered node and serial gateway setup to my laptop for testing. It presents the sensor node! The name and available sensors is correct. Howevr, it never sends any message payload with temp/hum or battery values. I am using the HTU21D without soldering those 3 pads on it together. I need to get myself a 3.3v FTDI cable so I can serially debug I guess. But, still! Progress.

@korttoma, excellent! I will try this out when I get home from work.

@FotoFieber, no. As I stated above this is my wiring:

A2 --> MISO
A1 --> MOSI
A0 --> SCK
6 --> CSN
5 --> CE

When I changed CSN/CE to the 2 pins you mentioned above it was and I was still getting this error:

A2 --> MISO
A1 --> MOSI
A0 --> SCK
53 --> CSN
40 --> CE

To use your wiring I would need to modify the rest of the pin definitions in the code, yes?

@FotoFieber
Builds and still I get the error:

0;255;3;0;9;Starting gateway (RNNGA-, 2.0.0)
0;255;3;0;9;TSM:INIT
0;255;3;0;9;!TSM:RADIO:FAIL
0;255;3;0;9;!TSM:FAILURE
0;255;3;0;9;TSM:PDT

@sundberg84
Yea, by my UNO is used for templating projects for my slimNode. I am only making the ethernet gateway because the direct-connection of the nrf to the RPi is not yet supporting v2 library. Just seems silly to include extra hardware (uno/mega and ethernet shield) when the RPi has GPIO and the nrf can be connected to it. I am using domoticz on the RPi using serial gateway but only with v1.4.

@sundberg84
I had read that. But, to be honest I could not make heads or tails about what the posters said did or did not work. There was no definitive answer on that thread. Some said try pins x/y/z and other said to try a/b/c. Yet, no one said "hey, this actually works". Closest was the comment by spugna85. But, looking at the v2 libraries it was already done (hence me using A0-2 pins).

I am using the following hookup on the ethernet shield to the nrf+:
A2 --> MISO
A1 --> MOSI
A0 --> SCK
6 --> CSN
5 --> CE

Well, I solved it by modifying the code to 2.0 spec. Good lord I need sleep.
Working on debugging temp outputs now to Ethernet Gateway running on my Uno. Or I will sleep...

I am trying to build the code using the HTU21D sensors. This built fine under 1.4 and 1.5 but now under v2 of MySensors I am getting this error:

C:\Users\wergeld\Documents\Arduino\SlimNodeSi7021\SlimNodeSi7021.ino:4:24: fatal error: MySensor.h: No such file or directory

 #include <MySensor.h>  

                        ^

compilation terminated.

exit status 1
Error compiling for board APM Optiboot internal 1MHz noBOD 9600baud.

Okay, so I change my reference to:

#include <MySensors.h>

And I get this lovely error:

In file included from C:\Users\wergeld\Documents\Arduino\SlimNodeSi7021\SlimNodeSi7021.ino:4:0:

C:\Users\wergeld\Documents\Arduino\libraries\MySensors-master/MySensors.h:287:4: error: #error No forward link or gateway feature activated. This means nowhere to send messages! Pretty pointless.

   #error No forward link or gateway feature activated. This means nowhere to send messages! Pretty pointless.

    ^

exit status 1
Error compiling for board APM Optiboot internal 1MHz noBOD 9600baud.

So, other than slamming my head against my desk how can I solve this?

I have the SEEEDstudio ethernet shield W5200 and am using the ethernet gateway code found here. This works fine with SOFTSPI enabled under Mysensors v2 library on my UNO. However, when I build the code out for my Mega 2056 i get this error on the serial monitor:

0;255;3;0;9;Starting gateway (RNNGA-, 2.0.0)
0;255;3;0;9;TSM:INIT
0;255;3;0;9;!TSM:RADIO:FAIL
0;255;3;0;9;!TSM:FAILURE
0;255;3;0;9;TSM:PDT

What am I missing here?

How can we update the gateway to v1.5? I just tried to rebuild from github today and I am getting really odd errors now that I did not get before:
cc1: error: bad value (cortex-a7)

What I could find online states I need to update the gcc compiler on my rPi - it is currently version 4 and latest is 5...but apt-get update gcc says I am already at latest version.

I am trying to get my slimNodes up and running using v1.5 of mysensors.

@siod
Is there any obstruction between the nodes and the gateway? Trees, walls, etc? Depending on what is in between the radios you can dramatically lose signal.

@GertSanders

Time to start reading up on converting the lib! Might have a go at it in week or so. Work is holding me hostage at the moment.

@tbowmo

What would be required to get the RPi gateway up and running? Having single controller/gateway is great.

@GertSanders What? I was under the impression that some features (like sending messages to nodes from domitcz wouldn't work).

@GertSanders I have seen no issues in Domoticz stable with CPU usage. Thing just purrs along. Will have to check when I get home but i believe my system uptime is approaching 1 year. It "just works" as they say.

I would like to upgrade to mysensors 2.0 library by it looks like the Pi repo has not being updated as often (last I checked, anyway).

@AWI said:

@wergeld congratulations
For the temp sensor I suggest a si7021 board. Almost the same price as as dht22 but more accurate, reliable and versatile. It uses the I2C bus (pin A4, A5)

@AWI I saw the si7021 on another forum. Ordered a couple of the low voltage ones as I want to make my nodes with as few components as possible. I could still use my thermistor while I wait. This is a fun build!

Finally had time to solder it. Not my best job, I admit. One of the caps I tried to mount was not flush enough so I had to clip it off. Hopefully not a critical component! I made the radio removable using some header strips. Now to figure out what temp sensor to use. I have currently used just a thermister. Can DHT22 work down at ~1.9V?

Anyway this was fun - highly recommend a needle point solder tip!

Finally got my v2 (red) boards in. Ended up with 30 of them. Will start wiring them up this week!

@drock1985 Right. I waited until a week after Chinese new year to order. Let the hangovers end and the trainstations empty . I am looking forward to finalizing my sensor network with cases as well. I have several old plastic/wood boxes lying around waiting for a less rats-nest setup.

You could also just use a thermistor (https://www.google.com/webhp?sourceid=chrome-instant&ion=1&espv=2&ie=UTF-8#q=10k+thermistor&tbm=shop). Cheap and not critically dependent on a particular voltage.

@m26872 Sounds good! Current status is "at board house." Getting twitchy waiting.

I have ordered these. Hopefully they can get here soon-ish. All my prototyping is done and the WAF is dropping steadily with all the wires and components lying around.

One question on this - separating the individual boards from the panel: dremel tool with cuter blade fine? Or do I need to use some other method?

I followed along with this tutorial: http://www.gammon.com.au/breadboard

It is very straight forward. If you need to add a clock to the chip you are trying to program you can do so via the "Alternate clock source" where he has put out an 8mhz signal on D9 you can use. All my bare-bones chips go through the process from gammon to start with then I mess with changing up any other options after.

@m26872 I am about to order the v2 version of the board and I have a few questions as I have never ordered PCBs before.
The defaults on ordering are:
layers - 2
thickness - 1.2 mm
coating - HASL
stencil - none

What are these options? I am tempted to just order as-is...for $14 what could I complain about? I am just curious what these other options are for.

Just wait until you run out of pins for the LEDs and you have to start charlieplexing. Crazy matrix computations but lots of fun!

@Mediacj I too had this error. The only way I was ever to solve this was to take a fresh image of Wheezy and start from scratch there. No sudo apt-get updated/upgrade until after I built the lib.

Just built this with my 4 year old. She loved it! She did the project management and directed me which wire goes where. Got to start them young!

I was really shocked at the brightness of the LED ring. I mean, I knew it would be bright from looking at the videos, but wow.

My setup was to connect my UNO to the PC, load code and branch power directly from the UNO's 5v pin. I had no cap or resistor in place either (neither was there a radio hooked-up). This was just a bench-top proof of concept and it worked right out the box (after I soldered leads to the ring). I went through all the adafruit example codes and worked without a hitch. I may, or may not, exceeded WAF level 10. Now she is giving me more projects for these "neopixel" lights.

Depending on your sensor setup they should be "sleeping" to conserve battery (if using battery). The sensors will only send messages when ordered to do so in code. The controller might send out ack signals depending on your setup but it is mostly in receive mode.

On a side note if you are worried about RF interference it goes down to what frequency and what channel you are on as well as your settings for power. Also any other emitting device in your house could interfere. If you are worried about health issues you shouldn't be. You get orders of magnitude more EMF radiation from the sun than you could get from these devices.

Update on the boards. It worked great on my RPi2 B. It did not fit on my RPi1 B due to the composite video jack preventing the shield from being seated fully. Guess I will need to de-solder that jack (dont have it hooked to video output anyway.

GertSanders,
All of my nodes are using 1.4 library. Oddly at around 2:30 am my one sensor I moved to same channel as my domoticz gateway got picked up. Pretty interesting! I had changed it to the domiticz channel at 11pm. Progress is good. Now going to see about why the temp is being reported as ~140 F when that sensor reported ~70 F (correct) when attached to my other controller.

Actually forgot that MyConfig file when I built the RPi gateway. That is all set but now when I debug using ./PiGatewaySerial i see good output for the radio parameters but then it spits out continuous reams of:

read: 0-0-0 s=0,c=0,t=0,pt=0,l=0:
version mismatch
read: 0-0-0 s=0,c=0,t=0,pt=0,l=0:
version mismatch
read: 0-0-0 s=0,c=0,t=0,pt=0,l=0:
version mismatch

Not sure what this is about as I do not have any nodes on this channel (76). All my active nodes are on channel 90 and are talking just fine to my RPi running easyIOT server.

What is this version mismatch about?

Finally got mysensors built on my RPi2. And have built domoiticz and it is up and running! I have added my USB gateway but now not sure what to do? It does not appear to pick up my sensor node. Where do I change the Gateway's channel and radio parameters?

I just got my boards. Not sure if this will work on my RPi2 though.

@mfalkvidd Yes, I used that to do the build initially. I cannot even get past the "make" command (tried sudo make as well). One person there had same error but they "solved it" and did not mention how they did it. I am going to give it another go tonight with a fresh image of raspbian.

@mfalkvidd Okay, that is what i was going to go for as well:
Try tmrh20 and then see what happens.

I think there is some issue with the code in general as the rpi2 does not have the bcm2835 chip, right? I think it is bcm2836 (mind not working this early in the morning).

@mfalkvidd I am attempting to follow your lead here on compiling the Raspberry mysensors gateway. However, this is failing on my rpi2 with tons of repeating errors like:
bcm2835.c: In function "bcm2835_init" :
error invalid suffix "x" on integer constant

I have enabled SPI from rasp-config. This is using the domoticz image of raspbian wheezy. Any thoughts on how to get around this?

I actually ordered two of these last week. Cant wait to try them out - will get rid of more of my rat's nest of wires and increase the WAF!