@CyborgAndy @vores8 and @TimO and everyone else that worked on getting this binding to work on OH3, you guys are rockstars. I fubar'd my OH2 installation and decided that i might as well upgrade to OH3. I'm so glad that the mysensors binding works with it. I'm running a Raspberry Pi Serial Gateway which amazingly also installed with only a few minor hick-ups. Thank you all so much!
I'm doing a brand new install of Openhab2 and the mysensors gateway on a new Raspberry Pi 4 after having run Openhab(1) and the mysensors gateway successfully on a Raspberry Pi 3 for years. I used the development branch of the mysensorsgateway as discussed here: https://github.com/mysensors/MySensors/pull/1364
I wrote down my step by step procedure here in case it helps someone else. I'm starting out with the pre-built Openhabian image found here: https://www.openhab.org/docs/installation/openhabian.html
Install the PiGatewaySerial using these instructions:
cd
cd Downloads
git clone https://github.com/mysensors/MySensors.git --branch development
cd MySensors
./configure --my-gateway=serial --my-serial-is-pty --my-serial-pty=/dev/ttyUSB20 --my-serial-groupname=tty
Edit: If building this on a 64bit operating system you will need to edit the configure file before running make. Do the following:
cp configure configure_bk
nano configure
Find this function
function gcc_cpu_flags {
local soc=$1
case $soc in
and find your CPU. In my case it is the BCM2711 (I've only done this on this one CPU so your mileage may vary) and I changed this:
BCM2711)
flags="-march=armv8-a+crc -mtune=cortex-a72 -mfpu=neon-fp-armv8 -mfloat-abi=hard"
to this:
BCM2711)
flags="-march=armv8-a+crc -mtune=cortex-a72"
Then proceed to step 4 below.
make
sudo make install
sudo systemctl enable mysgw.service
sudo systemctl start mysgw.service
cd /usr/local/bin
sudo mysgw
That's pretty much it. I was happily greeted with:
Dec 29 16:01:50 INFO Starting gateway...
Dec 29 16:01:50 INFO Protocol version - 2.4.0-alpha
Dec 29 16:01:50 DEBUG Serial port /dev/ttyUSB20 (115200 baud) created
Dec 29 16:01:50 DEBUG MCO:BGN:INIT GW,CP=RNNGL---,FQ=NA,REL=0,VER=2.4.0-alpha
Dec 29 16:01:50 DEBUG TSF:LRT:OK
Dec 29 16:01:50 DEBUG TSM:INIT
Dec 29 16:01:50 DEBUG TSF:WUR:MS=0
Dec 29 16:01:50 DEBUG TSM:INIT:TSP OK
Dec 29 16:01:50 DEBUG TSM:INIT:GW MODE
Dec 29 16:01:50 DEBUG TSM:READY:ID=0,PAR=0,DIS=0
Dec 29 16:01:50 DEBUG MCO:REG:NOT NEEDED
Dec 29 16:01:50 DEBUG MCO:BGN:STP
Dec 29 16:01:50 DEBUG MCO:BGN:INIT OK,TSP=1
Dec 29 16:01:50 DEBUG TSM:READY:NWD REQ
Dec 29 16:01:50 DEBUG ?TSF:MSG:SEND,0-0-255-255,s=255,c=3,t=20,pt=0,l=0,sg=0,ft=0,st=OK:
Dec 29 16:01:50 DEBUG TSF:MSG:READ,4-4-0,s=255,c=3,t=21,pt=1,l=1,sg=0:0
Dec 29 16:01:50 DEBUG TSF:MSG:READ,0-4-255,s=255,c=3,t=20,pt=0,l=0,sg=0:
Dec 29 16:01:50 DEBUG TSF:MSG:BC
Dec 29 16:01:52 DEBUG TSF:MSG:READ,4-4-0,s=1,c=1,t=2,pt=2,l=2,sg=0:0
Dec 29 16:01:52 DEBUG TSF:MSG:READ,4-4-0,s=2,c=1,t=2,pt=2,l=2,sg=0:0
Dec 29 16:01:52 DEBUG TSF:MSG:READ,4-4-0,s=3,c=1,t=2,pt=2,l=2,sg=0:1
Dec 29 16:01:52 DEBUG TSF:MSG:READ,4-4-0,s=4,c=1,t=2,pt=2,l=2,sg=0:1
^CDec 29 16:02:35 NOTICE Received SIGINT
I guess a better question would be to ask how I recompile everything into a new mysensorsbinding jar from here:
https://github.com/jerseyguy1996/openhab/tree/master/bundles/binding/org.openhab.binding.mysensors
I'm trying to add a handler for the I_DISCOVER_RESPONSE message that keeps spamming my openhab log. I've found the section of code in the openhab binding that controls that but I don't know how to recompile the software. I've tried editing MySensorsBinding.java and then executing the following command:
javac -classpath .:/home/pi/Downloads/org.openhab.binding.mysensors-1.8.0-SNAPSHOT.jar MySensorsBinding.java
My understanding is that all of the dependencies should be in the .jar file so I've included it in the class path. I really don't have a whole lot of experience programming where there are lots of dependencies so I don't know what I am doing. Any help would be great!
The github repository for MySensorsBinding.java is here:
This may be a stupid question, but I'm using the mysgateway on a Raspberry Pi as my controller which is described here:
Building a Raspberry Pi Gateway
The Raspberry pi runs headless and I do everything through ssh. Is there any way to use MYSBootloader using the mysgateway and initiating the OTA update using the command line?
I'm not too familiar with the Sonoff TH but I see in the description that it can work with the DS18B20 which uses the one-wire protocol meaning that you can daisy chain multiple sensors together on one communication line and then read them individually. I would start there and see how to have the Sonoff TH read two individually addressable DS18B20's on one communication line.
@marceloaqno Yes its 220 uF. It was all I had handy. I read somewhere that this may be a problem specific to the arduino nano. I may give it a try with the pro mini. Although I'm not sure what that may have to do with it.
Edit: I tried the same sketch on an arduino pro mini and it worked fine. When I simulated a loss of connection by walking out of range of the gateway it immediately reestablished the connection when I got back within range. The only difference is that the pro mini is running at 8 mhz whereas the nano runs at 16 mhz. Not sure how that affects things.
Has anyone else had an issue with getting a sensor node to reconnect after a lost connection? I can see it attempting to reconnect but even though it is back within range of the gateway it won't reestablish the connection. If I reset the node it re-establishes the connection without any problem. This is the cycle that it gets stuck in:
TSM:FPAR
TSP:MSG:SEND 3-3-255-255 s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=bc:
TSP:MSG:READ 0-0-3 s=255,c=3,t=8,pt=1,l=1,sg=0:0
TSP:MSG:FPAR RES (ID=0, dist=0)
TSP:MSG:PAR OK (ID=0, dist=1)
TSM:FPAR:OK
TSM:ID
TSM:CHKID:OK (ID=3)
TSM:UPL
TSP:PING:SEND (dest=0)
!TSP:MSG:SEND 3-3-0-0 s=255,c=3,t=24,pt=1,l=1,sg=0,ft=0,st=fail:1
TSP:CHKUPL:FAIL (hops=255)
!TSM:UPL:FAIL
TSM:FPAR
TSP:MSG:SEND 3-3-255-255 s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=bc:
!TSP:SEND:TNR
!TSP:SEND:TNR
!TSP:SEND:TNR
!TSP:SEND:TNR
!TSP:SEND:TNR
!TSP:SEND:TNR
TSM:FPAR
TSP:MSG:SEND 3-3-255-255 s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=bc:
TSP:MSG:READ 0-0-3 s=255,c=3,t=8,pt=1,l=1,sg=0:0
TSP:MSG:FPAR RES (ID=0, dist=0)
TSP:MSG:PAR OK (ID=0, dist=1)
TSM:FPAR:OK
TSM:ID
TSM:CHKID:OK (ID=3)
TSM:UPL
TSP:PING:SEND (dest=0)
!TSP:MSG:SEND 3-3-0-0 s=255,c=3,t=24,pt=1,l=1,sg=0,ft=0,st=fail:1
TSP:CHKUPL:FAIL (hops=255)
!TSM:UPL:FAIL
TSM:FPAR
TSP:MSG:SEND 3-3-255-255 s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=bc:
!TSP:SEND:TNR
!TSP:SEND:TNR
!TSP:SEND:TNR
!TSP:SEND:TNR
!TSP:SEND:TNR
!TSP:SEND:TNR```You can pretty much test out using any of the arduino examples here:
https://github.com/mysensors/MySensors/tree/development/examples
Each one will present itself to the gateway when it starts up and you will see the presentation in the debug log. Make sure to run:
https://github.com/mysensors/MySensors/tree/development/examples/ClearEepromConfig
on the arduino first to make sure it starts with a fresh eeprom. After you select an Arduino sketch to test it with (seriously it doesn't matter which one you try) make sure to look at the sketch and add:
// Enable and select radio type attached
#define MY_RADIO_NRF24
#define MY_NODE_ID 4
For MY_NODE_ID you can select any number. Just make sure that each new sensor node that you create has a different node number so like start out at MY_NODE_ID 1 and when you make another sensor node you can #define MY_NODE_ID 2 and so on.
Next load it up to the Arduino, open the serial monitor, and see what happens. If you watch the serial monitor on the arduino you will see it present itself to the gateway and then you can confirm it in the debug log on the raspberry pi.
I think it is pretty normal to have the problems you are having. I uninstalled and reinstalled the gateway 3 times on the Raspberry Pi before I finally got it all figured out. Once you get it running it is a glorious thing.
@bkl First off I want to thank you for the MySensors openhab binding. It works wonderfully!
In the MySensors 2.0 there is an internal message that doesn't seem to be handled by the binding. I believe it needs to be handled in MySensorsBinding.java. I would do it myself but my knowledge of Java sucks....to put it lightly. The internal message is:
I_DISCOVER_RESPONSE
so my openhab log keeps getting spammed with:
2016-10-21 22:16:21.653 [INFO ] [.b.m.internal.MySensorsBinding] - No item configured for "4;255;I_DISCOVER_RESPONSE"
2016-10-21 22:26:21.374 [INFO ] [.b.m.internal.MySensorsBinding] - No item configured for "4;255;I_DISCOVER_RESPONSE"
2016-10-21 22:36:22.127 [INFO ] [.b.m.internal.MySensorsBinding] - No item configured for "4;255;I_DISCOVER_RESPONSE"
2016-10-21 22:46:21.847 [INFO ] [.b.m.internal.MySensorsBinding] - No item configured for "4;255;I_DISCOVER_RESPONSE"
2016-10-21 22:56:21.569 [INFO ] [.b.m.internal.MySensorsBinding] - No item configured for "4;255;I_DISCOVER_RESPONSE"
I'm assuming that we just need to add a line to:
public void incommingMessage(Message message)
to handle it but I would rather let you do it since like I said....I suck with Java. Is that something that would be an easy fix?
@Christian-Simonsen If you don't have debug enabled you could also just use:
tail -f /dev/ttyUSB20
My port is named ttyUSB20. You should substitute whatever you have named your port.
Nevermind....When I set "--my-serial-groupname=tty" in ./configure it works.
I'm using the virtual serial port option and one of the things that I notice is that the port gets created where the tty group only has write access.
pi@raspberrypi:/dev/pts $ ls -l
total 0
crw--w---- 1 root tty 136, 0 Oct 10 18:49 0
I can change it manually but if I reboot the raspberry pi it goes back to write access only. How do I get it to be created with 'rw' access?
@marceloaqno Oh that makes sense 
I'm wondering if that is also what is causing my problem with reconnecting when the node loses contact with the gateway. The node connects perfectly when the gateway is running but if it loses the connection for any reason it can't seem to be able to reconnect and just goes into a loop of attempts. Here is the debug info from the node:
This is the initialization output
Starting sensor (RNNNA-, 2.0.0)
TSM:INIT
TSM:RADIO:OK
TSP:ASSIGNID:OK (ID=3)
TSM:FPAR
TSP:MSG:SEND 3-3-255-255 s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=bc:
TSP:MSG:READ 0-0-3 s=255,c=3,t=8,pt=1,l=1,sg=0:0
TSP:MSG:FPAR RES (ID=0, dist=0)
TSP:MSG:PAR OK (ID=0, dist=1)
TSM:FPAR:OK
TSM:ID
TSM:CHKID:OK (ID=3)
TSM:UPL
TSP:PING:SEND (dest=0)
TSP:MSG:SEND 3-3-0-0 s=255,c=3,t=24,pt=1,l=1,sg=0,ft=0,st=ok:1
TSP:MSG:READ 0-0-3 s=255,c=3,t=25,pt=1,l=1,sg=0:1
TSP:MSG:PONG RECV (hops=1)
TSP:CHKUPL:OK
TSM:UPL:OK
TSM:READY
TSP:MSG:SEND 3-3-0-0 s=255,c=3,t=15,pt=6,l=2,sg=0,ft=0,st=ok:0100
TSP:MSG:SEND 3-3-0-0 s=255,c=0,t=17,pt=0,l=5,sg=0,ft=0,st=ok:2.0.0
TSP:MSG:SEND 3-3-0-0 s=255,c=3,t=6,pt=1,l=1,sg=0,ft=0,st=ok:0
TSP:MSG:READ 0-0-3 s=255,c=3,t=15,pt=6,l=2,sg=0:0100
TSP:MSG:SEND 3-3-0-0 s=255,c=3,t=11,pt=0,l=11,sg=0,ft=0,st=ok:Sensor Node
TSP:MSG:SEND 3-3-0-0 s=255,c=3,t=12,pt=0,l=3,sg=0,ft=0,st=ok:1.0
TSP:MSG:SEND 3-3-0-0 s=1,c=0,t=6,pt=0,l=0,sg=0,ft=0,st=ok:
TSP:MSG:SEND 3-3-0-0 s=2,c=0,t=6,pt=0,l=0,sg=0,ft=0,st=ok:
TSP:MSG:SEND 3-3-0-0 s=3,c=0,t=3,pt=0,l=0,sg=0,ft=0,st=ok:
TSP:MSG:SEND 3-3-0-0 s=4,c=0,t=3,pt=0,l=0,sg=0,ft=0,st=ok:
TSP:MSG:SEND 3-3-0-0 s=5,c=0,t=3,pt=0,l=0,sg=0,ft=0,st=ok:
Request registration...
TSP:MSG:SEND 3-3-0-0 s=255,c=3,t=26,pt=1,l=1,sg=0,ft=0,st=ok:2
TSP:MSG:READ 0-0-3 s=255,c=3,t=27,pt=1,l=1,sg=0:1
Node registration=1
Init complete, id=3, parent=0, distance=1, registration=1
TSP:MSG:SEND 3-3-0-0 s=1,c=1,t=0,pt=7,l=5,sg=0,ft=0,st=ok:32.00
TSP:MSG:SEND 3-3-0-0 s=2,c=1,t=24,pt=3,l=2,sg=0,ft=0,st=ok:0
TSP:MSG:SEND 3-3-0-0 s=3,c=1,t=2,pt=1,l=1,sg=0,ft=0,st=ok:1
TSP:MSG:SEND 3-3-0-0 s=4,c=1,t=2,pt=1,l=1,sg=0,ft=0,st=ok:1
TSP:MSG:SEND 3-3-0-0 s=5,c=1,t=2,pt=1,l=1,sg=0,ft=0,st=ok:1
TSP:MSG:SEND 3-3-0-0 s=255,c=3,t=0,pt=1,l=1,sg=0,ft=0,st=ok:39
TSP:MSG:SEND 3-3-0-0 s=1,c=1,t=0,pt=7,l=5,sg=0,ft=0,st=ok:32.00
TSP:MSG:SEND 3-3-0-0 s=2,c=1,t=24,pt=3,l=2,sg=0,ft=0,st=ok:0
TSP:MSG:SEND 3-3-0-0 s=3,c=1,t=2,pt=1,l=1,sg=0,ft=0,st=ok:1
TSP:MSG:SEND 3-3-0-0 s=4,c=1,t=2,pt=1,l=1,sg=0,ft=0,st=ok:1
TSP:MSG:SEND 3-3-0-0 s=5,c=1,t=2,pt=1,l=1,sg=0,ft=0,st=ok:1
TSP:MSG:SEND 3-3-0-0 s=255,c=3,t=0,pt=1,l=1,sg=0,ft=0,st=ok:76
So far so good!
Next I shutdown the gateway to simulate a lost connection:
TSP:MSG:SEND 3-3-0-0 s=1,c=1,t=0,pt=7,l=5,sg=0,ft=0,st=ok:32.00
TSP:MSG:SEND 3-3-0-0 s=2,c=1,t=24,pt=3,l=2,sg=0,ft=0,st=ok:0
TSP:MSG:SEND 3-3-0-0 s=3,c=1,t=2,pt=1,l=1,sg=0,ft=0,st=ok:1
!TSP:MSG:SEND 3-3-0-0 s=4,c=1,t=2,pt=1,l=1,sg=0,ft=0,st=fail:1
!TSP:MSG:SEND 3-3-0-0 s=5,c=1,t=2,pt=1,l=1,sg=0,ft=1,st=fail:1
!TSP:MSG:SEND 3-3-0-0 s=255,c=3,t=0,pt=1,l=1,sg=0,ft=2,st=fail:74
!TSP:MSG:SEND 3-3-0-0 s=1,c=1,t=0,pt=7,l=5,sg=0,ft=3,st=fail:32.00
!TSP:MSG:SEND 3-3-0-0 s=2,c=1,t=24,pt=3,l=2,sg=0,ft=4,st=fail:0
!TSP:MSG:SEND 3-3-0-0 s=3,c=1,t=2,pt=1,l=1,sg=0,ft=5,st=fail:1
!TSP:MSG:SEND 3-3-0-0 s=4,c=1,t=2,pt=1,l=1,sg=0,ft=6,st=fail:1
!TSP:MSG:SEND 3-3-0-0 s=5,c=1,t=2,pt=1,l=1,sg=0,ft=7,st=fail:1
!TSP:MSG:SEND 3-3-0-0 s=255,c=3,t=0,pt=1,l=1,sg=0,ft=8,st=fail:72
Its still doing what I expect it to do. It begins attempting to reconnect:
!TSM:UPL FAIL, SNP
TSM:FPAR
TSP:MSG:SEND 3-3-255-255 s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=bc:
!TSP:SEND:TNR
!TSP:SEND:TNR
!TSP:SEND:TNR
!TSP:SEND:TNR
!TSP:SEND:TNR
!TSP:SEND:TNR
Fixing Transport Layer
TSM:FPAR
TSP:MSG:SEND 3-3-255-255 s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=bc:
TSM:FPAR
TSP:MSG:SEND 3-3-255-255 s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=bc:
!TSP:SEND:TNR
!TSP:SEND:TNR
!TSP:SEND:TNR
!TSP:SEND:TNR
!TSP:SEND:TNR
!TSP:SEND:TNR
Fixing Transport Layer
TSM:FPAR
TSP:MSG:SEND 3-3-255-255 s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=bc:
!TSM:FPAR:FAIL
!TSM:FAILURE
TSM:PDT
!TSP:SEND:TNR
!TSP:SEND:TNR
!TSP:SEND:TNR
!TSP:SEND:TNR
!TSP:SEND:TNR
!TSP:SEND:TNR
Still working as intended. Next I start the gateway back up to see if it will reconnect. Here is where I have problems.
Fixing Transport Layer
TSM:FPAR
TSP:MSG:SEND 3-3-255-255 s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=bc:
TSP:MSG:READ 0-0-3 s=255,c=3,t=8,pt=1,l=1,sg=0:0
TSP:MSG:FPAR RES (ID=0, dist=0)
TSP:MSG:PAR OK (ID=0, dist=1)
TSM:FPAR:OK
TSM:ID
TSM:CHKID:OK (ID=3)
TSM:UPL
TSP:PING:SEND (dest=0)
!TSP:MSG:SEND 3-3-0-0 s=255,c=3,t=24,pt=1,l=1,sg=0,ft=0,st=fail:1
TSP:CHKUPL:FAIL (hops=255)
!TSM:UPL:FAIL
TSM:FPAR
TSP:MSG:SEND 3-3-255-255 s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=bc:
!TSP:SEND:TNR
!TSP:SEND:TNR
!TSP:SEND:TNR
!TSP:SEND:TNR
!TSP:SEND:TNR
!TSP:SEND:TNR
Fixing Transport Layer
TSM:FPAR
TSP:MSG:SEND 3-3-255-255 s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=bc:
TSP:MSG:READ 0-0-3 s=255,c=3,t=8,pt=1,l=1,sg=0:0
TSP:MSG:FPAR RES (ID=0, dist=0)
TSP:MSG:PAR OK (ID=0, dist=1)
TSM:FPAR:OK
TSM:ID
TSM:CHKID:OK (ID=3)
TSM:UPL
TSP:PING:SEND (dest=0)
!TSP:MSG:SEND 3-3-0-0 s=255,c=3,t=24,pt=1,l=1,sg=0,ft=0,st=fail:1
TSP:CHKUPL:FAIL (hops=255)
!TSM:UPL:FAIL
TSM:FPAR
TSP:MSG:SEND 3-3-255-255 s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=bc:
!TSP:SEND:TNR
!TSP:SEND:TNR
!TSP:SEND:TNR
!TSP:SEND:TNR
!TSP:SEND:TNR
!TSP:SEND:TNR
It looks like the first few messages to initialize the reconnect go through okay and then it misses everything afterwards. If I reset the node it will connect again with no problems.
What do you think might be happening here?
@marceloaqno Amazing....adding the short delay fixed it! I'm curious why that is the case. Do you have an explanation for that?
Hello, I just installed @marceloaqno wonderful port of the mySensors 2.0 to the raspberry pi MyGatewaySerial. Thank you very much for that! I'm very glad to be using my boards that connect my radio directly to my Raspi! The installation went very smoothly.
I am having an issue with a few of my messages from my sensor node. My sensor node sends 6 messages. 3 are V-STATUS, 1 is V-TEMP, 1 is V-VAR1, and one is the battery voltage level. The V-TEMP and the 3 V-STATUS messages go through perfectly but the V-VAR1 and the Battery voltage are not reaching the Raspi. This is the output of the node:
Starting sensor (RNNNA-, 2.0.0)
TSM:INIT
TSM:RADIO:OK
TSP:ASSIGNID:OK (ID=3)
TSM:FPAR
TSP:MSG:SEND 3-3-255-255 s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=bc:
TSP:MSG:READ 0-0-3 s=255,c=3,t=8,pt=1,l=1,sg=0:0
TSP:MSG:FPAR RES (ID=0, dist=0)
TSP:MSG:PAR OK (ID=0, dist=1)
TSM:FPAR:OK
TSM:ID
TSM:CHKID:OK (ID=3)
TSM:UPL
TSP:PING:SEND (dest=0)
TSP:MSG:SEND 3-3-0-0 s=255,c=3,t=24,pt=1,l=1,sg=0,ft=0,st=ok:1
TSP:MSG:READ 0-0-3 s=255,c=3,t=25,pt=1,l=1,sg=0:1
TSP:MSG:PONG RECV (hops=1)
TSP:CHKUPL:OK
TSM:UPL:OK
TSM:READY
TSP:MSG:SEND 3-3-0-0 s=255,c=3,t=15,pt=6,l=2,sg=0,ft=0,st=ok:0100
TSP:MSG:SEND 3-3-0-0 s=255,c=0,t=17,pt=0,l=5,sg=0,ft=0,st=ok:2.0.0
TSP:MSG:SEND 3-3-0-0 s=255,c=3,t=6,pt=1,l=1,sg=0,ft=0,st=ok:0
TSP:MSG:READ 0-0-3 s=255,c=3,t=15,pt=6,l=2,sg=0:0100
TSP:MSG:SEND 3-3-0-0 s=255,c=3,t=11,pt=0,l=11,sg=0,ft=0,st=ok:Sensor Node
TSP:MSG:SEND 3-3-0-0 s=255,c=3,t=12,pt=0,l=3,sg=0,ft=0,st=ok:1.0
TSP:MSG:SEND 3-3-0-0 s=1,c=0,t=6,pt=0,l=0,sg=0,ft=0,st=ok:
TSP:MSG:SEND 3-3-0-0 s=2,c=0,t=6,pt=0,l=0,sg=0,ft=0,st=ok:
TSP:MSG:SEND 3-3-0-0 s=3,c=0,t=3,pt=0,l=0,sg=0,ft=0,st=ok:
TSP:MSG:SEND 3-3-0-0 s=4,c=0,t=3,pt=0,l=0,sg=0,ft=0,st=ok:
TSP:MSG:SEND 3-3-0-0 s=5,c=0,t=3,pt=0,l=0,sg=0,ft=0,st=ok:
Request registration...
TSP:MSG:SEND 3-3-0-0 s=255,c=3,t=26,pt=1,l=1,sg=0,ft=0,st=ok:2
TSP:MSG:READ 0-0-3 s=255,c=3,t=27,pt=1,l=1,sg=0:1
Node registration=1
Init complete, id=3, parent=0, distance=1, registration=1
Data = 0 0 0 0 0 0 0 0 0 0 CRC=0
Temperature = 0.00 Celsius, 32.00 Fahrenheit
TSP:MSG:SEND 3-3-0-0 s=1,c=1,t=0,pt=7,l=5,sg=0,ft=0,st=ok:32.00
!TSP:MSG:SEND 3-3-0-0 s=2,c=1,t=24,pt=3,l=2,sg=0,ft=0,st=fail:0
TSP:MSG:SEND 3-3-0-0 s=3,c=1,t=2,pt=1,l=1,sg=0,ft=1,st=ok:1
TSP:MSG:SEND 3-3-0-0 s=4,c=1,t=2,pt=1,l=1,sg=0,ft=0,st=ok:1
TSP:MSG:SEND 3-3-0-0 s=5,c=1,t=2,pt=1,l=1,sg=0,ft=0,st=ok:1
!TSP:MSG:SEND 3-3-0-0 s=255,c=3,t=0,pt=1,l=1,sg=0,ft=0,st=fail:44
No SensorTSP:MSG:SEND 3-3-0-0 s=1,c=1,t=0,pt=7,l=5,sg=0,ft=1,st=ok:0.00
!TSP:MSG:SEND 3-3-0-0 s=2,c=1,t=24,pt=3,l=2,sg=0,ft=0,st=fail:0
TSP:MSG:SEND 3-3-0-0 s=3,c=1,t=2,pt=1,l=1,sg=0,ft=1,st=ok:1
TSP:MSG:SEND 3-3-0-0 s=4,c=1,t=2,pt=1,l=1,sg=0,ft=0,st=ok:1
TSP:MSG:SEND 3-3-0-0 s=5,c=1,t=2,pt=1,l=1,sg=0,ft=0,st=ok:1
!TSP:MSG:SEND 3-3-0-0 s=255,c=3,t=0,pt=1,l=1,sg=0,ft=0,st=fail:60
Notice the failed messages on the "s=2" and "s=255" lines.
This is what the Raspi receives:
mysGateway: TSF:MSG:BC
mysGateway: TSF:MSG:FPAR REQ,ID=3
mysGateway: TSF:PNG:SEND,TO=0
mysGateway: TSF:CKU:OK
mysGateway: TSF:MSG:GWL OK
mysGateway: TSF:MSG:SEND,0-0-3-3,s=255,c=3,t=8,pt=1,l=1,sg=0,ft=0,st=OK:0
mysGateway: TSF:MSG:READ,3-3-0,s=255,c=3,t=24,pt=1,l=1,sg=0:1
mysGateway: TSF:MSG:PINGED,ID=3,HP=1
mysGateway: TSF:MSG:SEND,0-0-3-3,s=255,c=3,t=25,pt=1,l=1,sg=0,ft=0,st=OK:1
mysGateway: TSF:MSG:READ,3-3-0,s=255,c=3,t=15,pt=6,l=2,sg=0:0100
mysGateway: TSF:MSG:SEND,0-0-3-3,s=255,c=3,t=15,pt=6,l=2,sg=0,ft=0,st=OK:0100
mysGateway: TSF:MSG:READ,3-3-0,s=255,c=0,t=17,pt=0,l=5,sg=0:2.0.0
mysGateway: TSF:MSG:READ,3-3-0,s=255,c=3,t=6,pt=1,l=1,sg=0:0
mysGateway: TSF:MSG:READ,3-3-0,s=255,c=3,t=11,pt=0,l=11,sg=0:Sensor Node
mysGateway: TSF:MSG:READ,3-3-0,s=255,c=3,t=12,pt=0,l=3,sg=0:1.0
mysGateway: TSF:MSG:READ,3-3-0,s=1,c=0,t=6,pt=0,l=0,sg=0:
mysGateway: TSF:MSG:READ,3-3-0,s=2,c=0,t=6,pt=0,l=0,sg=0:
mysGateway: TSF:MSG:READ,3-3-0,s=3,c=0,t=3,pt=0,l=0,sg=0:
mysGateway: TSF:MSG:READ,3-3-0,s=4,c=0,t=3,pt=0,l=0,sg=0:
mysGateway: TSF:MSG:READ,3-3-0,s=5,c=0,t=3,pt=0,l=0,sg=0:
mysGateway: TSF:MSG:READ,3-3-0,s=255,c=3,t=26,pt=1,l=1,sg=0:2
mysGateway: TSF:MSG:SEND,0-0-3-3,s=255,c=3,t=27,pt=1,l=1,sg=0,ft=0,st=OK:1
mysGateway: TSF:MSG:READ,3-3-0,s=1,c=1,t=0,pt=7,l=5,sg=0:32.00
mysGateway: TSF:MSG:READ,3-3-0,s=3,c=1,t=2,pt=1,l=1,sg=0:1
mysGateway: TSF:MSG:READ,3-3-0,s=4,c=1,t=2,pt=1,l=1,sg=0:1
mysGateway: TSF:MSG:READ,3-3-0,s=5,c=1,t=2,pt=1,l=1,sg=0:1
mysGateway: TSF:MSG:READ,3-3-0,s=1,c=1,t=0,pt=7,l=5,sg=0:0.00
mysGateway: TSF:MSG:READ,3-3-0,s=3,c=1,t=2,pt=1,l=1,sg=0:1
mysGateway: TSF:MSG:READ,3-3-0,s=4,c=1,t=2,pt=1,l=1,sg=0:1
mysGateway: TSF:MSG:READ,3-3-0,s=5,c=1,t=2,pt=1,l=1,sg=0:1
This is the code running on the sensor node:
// Enable debug prints to serial monitor
#define MY_DEBUG
// Enable and select radio type attached
#define MY_RADIO_NRF24
#define MY_NODE_ID 3
#define MY_RF24_CE_PIN 9
#define MY_RF24_PA_LEVEL RF24_PA_HIGH
#include <SPI.h>
#include <MySensors.h>
#include <prescaler.h>
#include <OneWire.h>
#define SKETCH_NAME "Sensor Node"
#define SKETCH_MAJOR_VER "1"
#define SKETCH_MINOR_VER "0"
#define TEMPERATURE_SENSOR 1
#define STATUS 2
#define HIGH_SWITCH 3
#define FILL_SWITCH 4
#define LOW_SWITCH 5
const byte EN = 17; //turns on the boost converter to get 3.3v
const byte PER = 14; //peripherals (DS18B20, nRF24L01)
const byte High_sw = 5;
const byte Fill_sw = 6;
const byte Low_sw = 7;
const byte Wake_pin = 2; //wake from sleep mode powerdown
OneWire ds(9); // on pin 10 (a 4.7K resistor is necessary)
unsigned int node_status = 0;
// Change to V_LIGHT if you use S_LIGHT in presentation below
MyMessage msg(TEMPERATURE_SENSOR, V_TEMP);
MyMessage msg2(STATUS, V_VAR1);
MyMessage msg3(HIGH_SWITCH, V_STATUS);
MyMessage msg4(FILL_SWITCH, V_STATUS);
MyMessage msg5(LOW_SWITCH, V_STATUS);
void before(){
pinMode(EN,OUTPUT);
digitalWrite(EN,LOW); //give us 3.3v
pinMode(PER, OUTPUT); //for turning on peripherals
digitalWrite(PER,LOW); //peripherals on - P Chan FET
digitalWrite (Wake_pin, HIGH); //will wake with falling edge
}
void setup()
{
}
void presentation() {
// Send the sketch version information to the gateway and Controller
sendSketchInfo(SKETCH_NAME, SKETCH_MAJOR_VER "." SKETCH_MINOR_VER);
// Register binary input sensor to sensor_node (they will be created as child devices)
// You can use S_DOOR, S_MOTION or S_LIGHT here depending on your usage.
// If S_LIGHT is used, remember to update variable type you send in. See "msg" above.
present(TEMPERATURE_SENSOR, S_TEMP);
present(STATUS, S_TEMP);
present(HIGH_SWITCH, S_BINARY);
present(FILL_SWITCH, S_BINARY);
present(LOW_SWITCH, S_BINARY);
}
// Loop will iterate on changes on the BUTTON_PINs
void loop()
{
send(msg.set(get_temperature(),2));
send(msg2.set(node_status));
send(msg3.set(switch_status(High_sw)));
send(msg4.set(switch_status(Fill_sw)));
send(msg5.set(switch_status(Low_sw)));
sendBatteryLevel(get_battery());
//this worked when I was using the SerialGateway on the Raspi but
//isn't working using the MySerialGateway (mysgateway)
if(isTransportOK()){
sleep(30000); // transport is OK, node can sleep
}
else {
Serial.println("Fixing Transport Layer");
node_status+=1;
wait(5000); // transport is not operational, allow the transport layer to fix this
}
//sleep(60000); //interrupt on pin 2
}
bool switch_status(int digitalPin){
bool stat = 1;
pinMode(digitalPin,INPUT);
digitalWrite(digitalPin,HIGH); //enable pullup
sleep(5); //not sure if we need to wait for the line to settle
stat = digitalRead(digitalPin);
digitalWrite(digitalPin,LOW); //save power when off
return stat;
}
float get_temperature(){
byte i;
byte ds_present = 0;
byte type_s = 0;
byte data[12];
byte addr[8];
float celsius, fahrenheit;
if (!ds.reset())
{
Serial.print("No Sensor");
return (0);
}
ds.skip();
ds.write(0x44, 1); // start conversion, with parasite power on at the end
sleep(1000); // maybe 750ms is enough, maybe not
// we might do a ds.depower() here, but the reset will take care of it.
ds_present = ds.reset();
ds.skip();
ds.write(0xBE); // Read Scratchpad
Serial.print(" Data = ");
Serial.print(ds_present, HEX);
Serial.print(" ");
for ( i = 0; i < 9; i++) { // we need 9 bytes
data[i] = ds.read();
Serial.print(data[i], HEX);
Serial.print(" ");
}
Serial.print(" CRC=");
Serial.print(OneWire::crc8(data, 8), HEX);
Serial.println();
// Convert the data to actual temperature
// because the result is a 16 bit signed integer, it should
// be stored to an "int16_t" type, which is always 16 bits
// even when compiled on a 32 bit processor.
int16_t raw = (data[1] << 8) | data[0];
if (type_s) {
raw = raw << 3; // 9 bit resolution default
if (data[7] == 0x10) {
// "count remain" gives full 12 bit resolution
raw = (raw & 0xFFF0) + 12 - data[6];
}
} else {
byte cfg = (data[4] & 0x60);
// at lower res, the low bits are undefined, so let's zero them
if (cfg == 0x00) raw = raw & ~7; // 9 bit resolution, 93.75 ms
else if (cfg == 0x20) raw = raw & ~3; // 10 bit res, 187.5 ms
else if (cfg == 0x40) raw = raw & ~1; // 11 bit res, 375 ms
//// default is 12 bit resolution, 750 ms conversion time
}
celsius = (float)raw / 16.0;
fahrenheit = celsius * 1.8 + 32.0;
Serial.print(" Temperature = ");
Serial.print(celsius);
Serial.print(" Celsius, ");
Serial.print(fahrenheit);
Serial.println(" Fahrenheit");
return(fahrenheit);
}
//battery empty at .8v so 1.5 - .8 = .7
//(465-battery)/248
//.0032226562
float get_battery(){
unsigned int battery = analogRead(A1);
//float volts = 3.3/1024.0*(float)battery;
float percent = (217.0-(465.0-(float)battery))/217.0;
return(max(0,min(100,(percent * 100))));
}
Can you see anything that may be causing my issue?
@scalz Thanks for all of your advice! It's nice to get help from someone who has already successfully made a ulpnode.
@Yveaux I was having this problem in my test script which was just the GettingStarted example script on the RF24 library. I solved it by simply re-transmitting if the first one failed. It never took more than 2 trys. I just don't know how to force the mysensors library to retry the transmission if the first attempt fails.
Thanks for the feedback! I think some of the issues that you highlight are correct but some are actually covered in my design. I'll try to address each one and I would love to hear any additional feedback and if my explanation addresses these issues.
- I have not looked deep, but you may have some pin floating. It's not a good practice to not put pullup on mosfet, because you can miss a case and let the place to floating state. When you know exactly what you do and schematic is wired in a way, it's ok. So if you may have a floating state on your radio mosfet, it could be the problem. Try to add a pull-up if it helps.
You are correct that this is an issue. This is actually my 3rd build of this board and I've been fixing little problems along the way. This will be addressed in the next iteration.
- sequence not complete. Why nothing connected to the input of your supervisor, it's useless like this. To have a reliable sequence without having to rely on software (as ulpnode works), you have to connect the input of supervisor to your vcc.
If you look closely at the schematic, VCC is connected to the input of the supervisor. It is connected at pin 2 of the device. The sleep/wake up functionality of the board is currently working fine.
- about power consumption, I think you have not checked the power consumption yet and you could be disappointed! because you don't disconnect the resistor divider of the booster from gnd. So there is a big consumption there.
In this case my total resistance across that divider is 1.5Mohms so the current even when VCC is at 3.3V is about 2.15 uA. Certainly high compared to the nanoAmp draw that we are attempting but for my use I can live with it.
- You're using an inverter supervisor on output. It's not low power too. you should use mosfet and connect it to your booster...and be careful with the booster en pin not floating during wiring everything.
Good call....I'll switch that one out on the next iteration for a mosfet
- for the mcp1640 I hope you choosed the MCP1640 or MCP1640T variant as others are less efficient for your case.
Yes I'm using this one: MCP1640T-I/CHY
- you could need a uCurrent. A simple multimeter is not enough. and a scope is very useful too sometimes.
I'm not trying to make it absolutely low power...I just want to not have to change the battery more than once a year. I rough estimated my current consumption by timing the discharge of the 470uF storage capacitor. My sleep to wake period is right at 30 seconds so the capacitor has to discharge from 3.3v down to 2.0v over that time. That gives me a peak current in sleep mode of about 26uA.....certainly not the nano amp level that Charles Hallarde was able to get but it is fine for my implementation. A typical AAA battery has about 1000 mAh of useful capacity so at 26uA continuous draw (ignoring the short on times) I should have a useful battery life of about 38500 hours or about 4.39 years........which is more than enough.
What are your thoughts?
@scalz Yes you are correct in that I am making a ULPNode :-). I need it for monitoring various parts of a salt water aquarium and I don't want to have to have power cords going everywhere. The node I made actually works great as far as being able to go to sleep, wake up with the interrupt from the voltage monitor, power on the radio and sensors, and then transmit out its data before going back to sleep. It just seems to be having trouble with the MySensors sleep functionality. I may just use the sleep(ms) function until I can figure it out.
I had already tried most of your suggestions so I guess great minds think alike 
Below is the link for my ULPNode. It has a connection for a DS18B20 temperature sensor and 3 float switches which are used for water levels. It also has an input for the raw battery voltage so that it can monitor its battery levels and notify me when it needs to be changed.
What do you mean by "pir"? What does that stand for?
@tekka I threw a wdt_reset() in there but still no joy. It also seems like most of the transmissions are failing when it comes out of sleep mode. Also there is a particular transmission that if it fails I've noticed the node gets stuck and won't go back to sleep. It's very perplexing.
I have a node that wakes from an external signal (voltage monitor). When it wakes up, the Gateway sees all of the presentation material as though the node is being powered up for the first time. The sketch looks like this:
/ Enable debug prints to serial monitor
#define MY_DEBUG
// Enable and select radio type attached
#define MY_RADIO_NRF24
#define MY_NODE_ID 3
#define MY_RF24_CE_PIN 8
#include <SPI.h>
#include <MySensors.h>
#include <prescaler.h>
#define SKETCH_NAME "Sensor Node"
#define SKETCH_MAJOR_VER "1"
#define SKETCH_MINOR_VER "0"
#define TEMPERATURE_SENSOR 1
const byte EN = 17; //turns on the boost converter to get 3.3v
const byte PER = 14; //peripherals (DS18B20, nRF24L01)
const byte Wake_pin = 2; //wake from sleep mode powerdown
// Change to V_LIGHT if you use S_LIGHT in presentation below
MyMessage msg(TEMPERATURE_SENSOR, V_TEMP);
void before(){
pinMode(EN,OUTPUT);
digitalWrite(EN,LOW); //give us 3.3v
pinMode(PER, OUTPUT); //for turning on peripherals
digitalWrite(PER,LOW); //peripherals on - P Chan FET
digitalWrite (Wake_pin, HIGH); //will wake with falling edge
}
void setup()
{
}
void presentation() {
// Send the sketch version information to the gateway and Controller
sendSketchInfo(SKETCH_NAME, SKETCH_MAJOR_VER "." SKETCH_MINOR_VER);
// Register binary input sensor to sensor_node (they will be created as child devices)
// You can use S_DOOR, S_MOTION or S_LIGHT here depending on your usage.
// If S_LIGHT is used, remember to update variable type you send in. See "msg" above.
present(TEMPERATURE_SENSOR, S_TEMP);
}
// Loop will iterate on changes on the BUTTON_PINs
void loop()
{
send(msg.set(20));
//we slow the CPU down so that it can run down to 1.8 volts safely. The voltage
//monitor will wake it up when the capacitor voltage drops from 3.3 volts
//down to 2 volts
setClockPrescaler(CLOCK_PRESCALER_4); //bring the cpu to slow speed
sleep(0,FALLING); //interrupt on pin 2
//the boost converter has been enabled so it is safe to bring the CPU
//back up to full speed.
setClockPrescaler(CLOCK_PRESCALER_1); //bring the cpu back to full speed
}
This is the output from the Gateway. I've shown a couple of full sleep >> wake cycles. I added a space between the end of one cycle and the beginning of the next. As you can see, the node sends the data, and then it goes through the whole initiation process. It doesn't do this when using the sleep function that is just based on the WDT. Is it supposed to do this?
3;1;1;0;0;20
0;255;3;0;9;TSP:MSG:READ 3-3-255 s=255,c=3,t=7,pt=0,l=0,sg=0:
0;255;3;0;9;TSP:MSG:BC
0;255;3;0;9;TSP:MSG:FPAR REQ (sender=3)
0;255;3;0;9;TSP:CHKUPL:OK
0;255;3;0;9;TSP:MSG:GWL OK
0;255;3;0;9;TSP:MSG:SEND 0-0-3-3 s=255,c=3,t=8,pt=1,l=1,sg=0,ft=0,st=ok:0
0;255;3;0;9;TSP:MSG:READ 3-3-0 s=255,c=3,t=24,pt=1,l=1,sg=0:1
0;255;3;0;9;TSP:MSG:PINGED (ID=3, hops=1)
0;255;3;0;9;TSP:MSG:SEND 0-0-3-3 s=255,c=3,t=25,pt=1,l=1,sg=0,ft=0,st=ok:1
0;255;3;0;9;TSP:MSG:READ 3-3-0 s=255,c=3,t=15,pt=6,l=2,sg=0:0100
0;255;3;0;9;TSP:MSG:SEND 0-0-3-3 s=255,c=3,t=15,pt=6,l=2,sg=0,ft=0,st=ok:0100
0;255;3;0;9;TSP:MSG:READ 3-3-0 s=255,c=0,t=17,pt=0,l=5,sg=0:2.0.0
3;255;0;0;17;2.0.0
0;255;3;0;9;TSP:MSG:READ 3-3-0 s=255,c=3,t=6,pt=1,l=1,sg=0:0
3;255;3;0;6;0
0;255;3;0;9;TSP:MSG:READ 3-3-0 s=255,c=3,t=11,pt=0,l=11,sg=0:Sensor Node
3;255;3;0;11;Sensor Node
0;255;3;0;9;TSP:MSG:READ 3-3-0 s=255,c=3,t=12,pt=0,l=3,sg=0:1.0
3;255;3;0;12;1.0
0;255;3;0;9;TSP:MSG:READ 3-3-0 s=1,c=0,t=6,pt=0,l=0,sg=0:
3;1;0;0;6;
0;255;3;0;9;TSP:MSG:READ 3-3-0 s=255,c=3,t=26,pt=1,l=1,sg=0:2
0;255;3;0;9;TSP:MSG:SEND 0-0-3-3 s=255,c=3,t=27,pt=1,l=1,sg=0,ft=0,st=ok:1
0;255;3;0;9;TSP:MSG:READ 3-3-0 s=1,c=1,t=0,pt=2,l=2,sg=0:20
3;1;1;0;0;20
0;255;3;0;9;TSP:MSG:READ 3-3-0 s=1,c=1,t=0,pt=2,l=2,sg=0:20
3;1;1;0;0;20
0;255;3;0;9;TSP:MSG:READ 3-3-255 s=255,c=3,t=7,pt=0,l=0,sg=0:
0;255;3;0;9;TSP:MSG:BC
0;255;3;0;9;TSP:MSG:FPAR REQ (sender=3)
0;255;3;0;9;TSP:CHKUPL:OK
0;255;3;0;9;TSP:MSG:GWL OK
0;255;3;0;9;TSP:MSG:SEND 0-0-3-3 s=255,c=3,t=8,pt=1,l=1,sg=0,ft=0,st=ok:0
0;255;3;0;9;TSP:MSG:READ 3-3-0 s=255,c=3,t=24,pt=1,l=1,sg=0:1
0;255;3;0;9;TSP:MSG:PINGED (ID=3, hops=1)
0;255;3;0;9;!TSP:MSG:SEND 0-0-3-3 s=255,c=3,t=25,pt=1,l=1,sg=0,ft=0,st=fail:1
0;255;3;0;9;TSP:MSG:READ 3-3-0 s=255,c=3,t=15,pt=6,l=2,sg=0:0100
0;255;3;0;9;TSP:MSG:SEND 0-0-3-3 s=255,c=3,t=15,pt=6,l=2,sg=0,ft=0,st=ok:0100
0;255;3;0;9;TSP:MSG:READ 3-3-0 s=255,c=0,t=17,pt=0,l=5,sg=0:2.0.0
3;255;0;0;17;2.0.0
0;255;3;0;9;TSP:MSG:READ 3-3-0 s=255,c=3,t=6,pt=1,l=1,sg=0:0
3;255;3;0;6;0
0;255;3;0;9;TSP:SANCHK:OK
0;255;3;0;9;TSP:MSG:READ 3-3-0 s=255,c=3,t=11,pt=0,l=11,sg=0:Sensor Node
3;255;3;0;11;Sensor Node
0;255;3;0;9;TSP:MSG:READ 3-3-0 s=255,c=3,t=12,pt=0,l=3,sg=0:1.0
3;255;3;0;12;1.0
0;255;3;0;9;TSP:MSG:READ 3-3-0 s=1,c=0,t=6,pt=0,l=0,sg=0:
3;1;0;0;6;
0;255;3;0;9;TSP:MSG:READ 3-3-0 s=255,c=3,t=26,pt=1,l=1,sg=0:2
0;255;3;0;9;TSP:MSG:SEND 0-0-3-3 s=255,c=3,t=27,pt=1,l=1,sg=0,ft=0,st=ok:1
0;255;3;0;9;TSP:MSG:READ 3-3-0 s=1,c=1,t=0,pt=2,l=2,sg=0:20
3;1;1;0;0;20
One other possibly relevant thing is that I modified the file MyHwATMega328.cpp in function:
void hwPowerDown(period_t period)
to include a few lines to manipulate the pins that enable and disable the boost converter on the board:
sei();
DDRC &= ~(1<<3); //disable boost converter
PORTC &= ~(1<<3);
// sleep until WDT or ext. interrupt
sleep_cpu();
sleep_disable();
DDRC |= (1<<3); //enable boost converter
PORTC |= (1<<3);
// restore previous WDT settings
@scalz Oh ya that makes sense regarding the before() and setup().
Regarding the sketch that doesn't include the radio turn off....I was just referring to the one that had the relevant lines commented out so:
void loop()
{
send(msg.set(20));
//digitalWrite (PER, HIGH); //turn off peripherals
// Sleep for 10 seconds (just for testing)
sleep(10000);
//digitalWrite (PER, LOW); //turn on peripherals
//delay(1000); //tried instituting a delay in case it needed a moment for power to stabilize
//transportInit(); //re-initialize radio
}
instead of:
void loop()
{
send(msg.set(20));
digitalWrite (PER, HIGH); //turn off peripherals
// Sleep for 10 seconds (just for testing)
sleep(10000);
digitalWrite (PER, LOW); //turn on peripherals
//delay(1000); //tried instituting a delay in case it needed a moment for power to stabilize
transportInit(); //re-initialize radio
}
@scalz Well that seems to have fixed the radio init problem and the Gateway exploding problem although I'm not sure how. Seems like I should be able to initialize my i/o pins anywhere in the sketch. Of course I'm not much of a programmer so it's not uncommon for me to not know why or how something works Thank you for that!!!
Now I have a second issue. The sketch that doesn't include the radio turn off functionality sends data to an Openhab MySensors binding every 10 seconds. When I add the radio turn off functionality the binding catches two data points and then nothing after although the arduino serial monitor shows that the transmissions are successful. Here is the Serial monitor output:
TSP:MSG:SEND 3-3-0-0 s=1,c=1,t=0,pt=2,l=2,sg=0,ft=0,st=ok:20
TSP:MSG:SEND 3-3-0-0 s=1,c=1,t=0,pt=2,l=2,sg=0,ft=0,st=ok:20
TSP:MSG:SEND 3-3-0-0 s=1,c=1,t=0,pt=2,l=2,sg=0,ft=0,st=ok:20
TSP:MSG:SEND 3-3-0-0 s=1,c=1,t=0,pt=2,l=2,sg=0,ft=0,st=ok:20
TSP:MSG:SEND 3-3-0-0 s=1,c=1,t=0,pt=2,l=2,sg=0,ft=0,st=ok:20
TSP:MSG:SEND 3-3-0-0 s=1,c=1,t=0,pt=2,l=2,sg=0,ft=0,st=ok:20
TSP:MSG:SEND 3-3-0-0 s=1,c=1,t=0,pt=2,l=2,sg=0,ft=0,st=ok:20
Here is the Openhab log:
2016-07-23 17:05:27.921 [DEBUG] [.b.m.internal.MySensorsBinding] - I_LOG_MESSAGE: TSP:MSG:READ 3-3-0 s=1,c=1,t=0,pt=2,l=2,sg=0:20
2016-07-23 17:05:27.923 [DEBUG] [.b.m.internal.MySensorsBinding] - DTank = 20
2016-07-23 17:05:27.923 [DEBUG] [.b.m.internal.MySensorsBinding] - internalReceiveUpdate(DTank,20) is called!
2016-07-23 17:05:30.107 [DEBUG] [.b.m.internal.MySensorsBinding] - Gateway Version: 2.0.0
2016-07-23 17:05:31.236 [DEBUG] [.o.m.c.i.folder.FolderObserver] - Refreshing folder 'sitemaps'
2016-07-23 17:05:31.238 [DEBUG] [.o.m.c.i.folder.FolderObserver] - Refreshing folder 'persistence'
2016-07-23 17:05:31.240 [DEBUG] [.o.m.c.i.folder.FolderObserver] - Refreshing folder 'rules'
2016-07-23 17:05:31.242 [DEBUG] [.o.m.c.i.folder.FolderObserver] - Refreshing folder 'scripts'
2016-07-23 17:05:31.244 [DEBUG] [.o.m.c.i.folder.FolderObserver] - Refreshing folder 'items'
2016-07-23 17:05:39.976 [DEBUG] [.b.m.internal.MySensorsBinding] - I_LOG_MESSAGE: TSP:MSG:READ 3-3-0 s=1,c=1,t=0,pt=2,l=2,sg=0:20
2016-07-23 17:05:39.978 [DEBUG] [.b.m.internal.MySensorsBinding] - DTank = 20
2016-07-23 17:05:39.978 [DEBUG] [.b.m.internal.MySensorsBinding] - internalReceiveUpdate(DTank,20) is called!
2016-07-23 17:05:41.246 [DEBUG] [.o.m.c.i.folder.FolderObserver] - Refreshing folder 'sitemaps'
2016-07-23 17:05:41.248 [DEBUG] [.o.m.c.i.folder.FolderObserver] - Refreshing folder 'persistence'
2016-07-23 17:05:41.250 [DEBUG] [.o.m.c.i.folder.FolderObserver] - Refreshing folder 'rules'
2016-07-23 17:05:41.252 [DEBUG] [.o.m.c.i.folder.FolderObserver] - Refreshing folder 'scripts'
2016-07-23 17:05:41.254 [DEBUG] [.o.m.c.i.folder.FolderObserver] - Refreshing folder 'items'
2016-07-23 17:05:46.365 [DEBUG] [.b.m.internal.MySensorsBinding] - I_LOG_MESSAGE: TSP:SANCHK:OK
2016-07-23 17:05:51.257 [DEBUG] [.o.m.c.i.folder.FolderObserver] - Refreshing folder 'sitemaps'
2016-07-23 17:05:51.259 [DEBUG] [.o.m.c.i.folder.FolderObserver] - Refreshing folder 'persistence'
2016-07-23 17:05:51.261 [DEBUG] [.o.m.c.i.folder.FolderObserver] - Refreshing folder 'rules'
2016-07-23 17:05:51.263 [DEBUG] [.o.m.c.i.folder.FolderObserver] - Refreshing folder 'scripts'
2016-07-23 17:05:51.265 [DEBUG] [.o.m.c.i.folder.FolderObserver] - Refreshing folder 'items'
2016-07-23 17:06:01.268 [DEBUG] [.o.m.c.i.folder.FolderObserver] - Refreshing folder 'sitemaps'
2016-07-23 17:06:01.270 [DEBUG] [.o.m.c.i.folder.FolderObserver] - Refreshing folder 'persistence'
2016-07-23 17:06:01.272 [DEBUG] [.o.m.c.i.folder.FolderObserver] - Refreshing folder 'rules'
2016-07-23 17:06:01.274 [DEBUG] [.o.m.c.i.folder.FolderObserver] - Refreshing folder 'scripts'
2016-07-23 17:06:01.276 [DEBUG] [.o.m.c.i.folder.FolderObserver] - Refreshing folder 'items'
2016-07-23 17:06:11.278 [DEBUG] [.o.m.c.i.folder.FolderObserver] - Refreshing folder 'sitemaps'
2016-07-23 17:06:11.280 [DEBUG] [.o.m.c.i.folder.FolderObserver] - Refreshing folder 'persistence'
2016-07-23 17:06:11.282 [DEBUG] [.o.m.c.i.folder.FolderObserver] - Refreshing folder 'rules'
2016-07-23 17:06:11.284 [DEBUG] [.o.m.c.i.folder.FolderObserver] - Refreshing folder 'scripts'
2016-07-23 17:06:11.286 [DEBUG] [.o.m.c.i.folder.FolderObserver] - Refreshing folder 'items'
2016-07-23 17:06:21.288 [DEBUG] [.o.m.c.i.folder.FolderObserver] - Refreshing folder 'sitemaps'
2016-07-23 17:06:21.290 [DEBUG] [.o.m.c.i.folder.FolderObserver] - Refreshing folder 'persistence'
2016-07-23 17:06:21.292 [DEBUG] [.o.m.c.i.folder.FolderObserver] - Refreshing folder 'rules'
2016-07-23 17:06:21.294 [DEBUG] [.o.m.c.i.folder.FolderObserver] - Refreshing folder 'scripts'
2016-07-23 17:06:21.295 [DEBUG] [.o.m.c.i.folder.FolderObserver] - Refreshing folder 'items'
2016-07-23 17:06:30.109 [DEBUG] [.b.m.internal.MySensorsBinding] - Gateway Version: 2.0.0
2016-07-23 17:06:31.297 [DEBUG] [.o.m.c.i.folder.FolderObserver] - Refreshing folder 'sitemaps'
2016-07-23 17:06:31.299 [DEBUG] [.o.m.c.i.folder.FolderObserver] - Refreshing folder 'persistence'
2016-07-23 17:06:31.301 [DEBUG] [.o.m.c.i.folder.FolderObserver] - Refreshing folder 'rules'
2016-07-23 17:06:31.303 [DEBUG] [.o.m.c.i.folder.FolderObserver] - Refreshing folder 'scripts'
2016-07-23 17:06:31.305 [DEBUG] [.o.m.c.i.folder.FolderObserver] - Refreshing folder 'items'
2016-07-23 17:06:41.307 [DEBUG] [.o.m.c.i.folder.FolderObserver] - Refreshing folder 'sitemaps'
2016-07-23 17:06:41.309 [DEBUG] [.o.m.c.i.folder.FolderObserver] - Refreshing folder 'persistence'
2016-07-23 17:06:41.311 [DEBUG] [.o.m.c.i.folder.FolderObserver] - Refreshing folder 'rules'
2016-07-23 17:06:41.313 [DEBUG] [.o.m.c.i.folder.FolderObserver] - Refreshing folder 'scripts'
2016-07-23 17:06:41.315 [DEBUG] [.o.m.c.i.folder.FolderObserver] - Refreshing folder 'items'
2016-07-23 17:06:46.342 [DEBUG] [.b.m.internal.MySensorsBinding] - I_LOG_MESSAGE: TSP:SANCHK:OK
You can see that it catches two data transmissions and then nothing after. It works fine without transportInit() being called so I am a bit confused by it.
A few additional data points to ponder. If I run that sketch above it gives the wacky output that I pasted above. If I roll back the sketch to a previously working version (i.e. just commenting out the lines that turn the radio off and back on again) like this:
void loop()
{
send(msg.set(20));
//digitalWrite (PER, HIGH); //turn off peripherals
// Sleep for 10 seconds (just for testing)
sleep(10000);
//digitalWrite (PER, LOW); //turn on peripherals
//delay(1000); //tried instituting a delay in case it needed a moment for power to stabilize
//transportInit(); //re-initialize radio
}
..the sketch still doesn't work. It requires me resetting the actual gateway that is attached to my Raspi before it will start to work again. So basically this sketch:
void loop()
{
send(msg.set(20));
digitalWrite (PER, HIGH); //turn off peripherals
// Sleep for 10 seconds (just for testing)
sleep(10000);
digitalWrite (PER, LOW); //turn on peripherals
//delay(1000); //tried instituting a delay in case it needed a moment for power to stabilize
transportInit(); //re-initialize radio
}
..causes the gateway to go haywire.
I'm working on a sensor node that is set up to be able to turn off power to all of the peripherals (sensors, radio) when the arduino goes to sleep to minimize power consumption. When it wakes up it re-energizes the bus and I need to re-initialize the radio which I thought was what calling transportInit() does. It doesn't seem to be working out though. Below is my code:
// Enable debug prints to serial monitor
#define MY_DEBUG
// Enable and select radio type attached
#define MY_RADIO_NRF24
#define MY_NODE_ID 3
#define MY_RF24_CE_PIN 8
#include <SPI.h>
#include <MySensors.h>
#include <prescaler.h>
#define SKETCH_NAME "Sensor Node"
#define SKETCH_MAJOR_VER "1"
#define SKETCH_MINOR_VER "0"
#define TEMPERATURE_SENSOR 1
const byte EN = 17; //turns on the boost converter to get 3.3v
const byte PER = 14; //peripherals (DS18B20, nRF24L01)
const byte Wake_pin = 2; //wake from sleep mode powerdown
// Change to V_LIGHT if you use S_LIGHT in presentation below
MyMessage msg(TEMPERATURE_SENSOR, V_TEMP);
void setup()
{
pinMode(EN,OUTPUT);
digitalWrite(EN,LOW); //give us 3.3v
pinMode(PER, OUTPUT); //for turning on peripherals
digitalWrite(PER,LOW); //peripherals on - P Chan FET
digitalWrite (Wake_pin, HIGH); //will wake with falling edge
}
void presentation() {
// Send the sketch version information to the gateway and Controller
sendSketchInfo(SKETCH_NAME, SKETCH_MAJOR_VER "." SKETCH_MINOR_VER);
// Register binary input sensor to sensor_node (they will be created as child devices)
// You can use S_DOOR, S_MOTION or S_LIGHT here depending on your usage.
// If S_LIGHT is used, remember to update variable type you send in. See "msg" above.
present(TEMPERATURE_SENSOR, S_TEMP);
}
// Loop will iterate on changes on the BUTTON_PINs
void loop()
{
send(msg.set(20));
digitalWrite (PER, HIGH); //turn off peripherals - PER is connected to a P-Chan Fet
// Sleep for 10 seconds (just for testing)
sleep(10000);
digitalWrite (PER, LOW); //turn on peripherals
//delay(1000); //tried instituting a delay in case it needed a moment for power to stabilize
transportInit(); //re-initialize radio
}
Looking at the library files it seems that transportInit() just calls RF24_Initialize() in the RF24.cpp library file and RF24_Initialize() appears to do everything it needs to do to get the radio back up to snuff. The DEBUG output on the arduino serial monitor has a lot of different things. Below is a sample of the various messages:
Starting sensor (RNNNA-, 2.0.0)
TSM:INIT
!TSM:RADIO:FAIL
!TSM:FAILURE
TSM:PDT
TSM:INIT
TSM:RADIO:OK
TSP:ASSIGNID:OK (ID=3)
TSM:FPAR
TSP:MSG:SEND 3-3-255-255 s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=bc:
TSP:MSG:READ 0-0-0 s=0,c=0,t=0,pt=0,l=0,sg=0:
!TSP:MSG:PVER mismatch
TSP:MSG:READ 0-0-0 s=0,c=0,t=0,pt=0,l=0,sg=0:
!TSP:MSG:PVER mismatch
TSP:MSG:READ 0-0-0 s=0,c=0,t=0,pt=0,l=0,sg=0:
!TSP:MSG:PVER mismatch
TSM:FPAR
TSP:MSG:SEND 3-3-255-255 s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=bc:
TSM:PDT
!TSP:SEND:TNR
!TSP:SEND:TNR
!TSP:SEND:TNR
!TSP:SEND:TNR
!TSP:SEND:TNR
In the openhab log I get a lot of this:
2016-07-23 15:50:51.139 [DEBUG] [.b.m.internal.MySensorsBinding] - I_LOG_MESSAGE: TSP:MSG:READ 3-3-255 s=255,c=3,t=7,pt=0,l=0,sg=0:
2016-07-23 15:50:51.141 [DEBUG] [.b.m.internal.MySensorsBinding] - I_LOG_MESSAGE: TSP:MSG:BC
2016-07-23 15:50:51.142 [DEBUG] [.b.m.internal.MySensorsBinding] - I_LOG_MESSAGE: TSP:MSG:FPAR REQ (sender=3)
2016-07-23 15:50:51.143 [DEBUG] [.b.m.internal.MySensorsBinding] - I_LOG_MESSAGE: TSP:CHKUPL:OK
2016-07-23 15:50:51.144 [DEBUG] [.b.m.internal.MySensorsBinding] - I_LOG_MESSAGE: TSP:MSG:GWL OK
2016-07-23 15:50:51.974 [DEBUG] [.b.m.internal.MySensorsBinding] - I_LOG_MESSAGE: !TSP:MSG:SEND 0-0-3-3 s=255,c=3,t=8,pt=1,l=1,sg=0,ft=0,st=fail:0
Any thoughts would be greatly appreciated!
@Lars65 I've used the SMD version in some of my designs. I find it easier to just solder the module right to the board rather than plug it into a header. Mine work great! I've read that at that price point they are probably counterfeit chips as the Nordic Semiconductor nRF24L01+ chips are quite a bit more expensive than that whole board, but they work fine.
First question: Is the GatewaySerial.ino sketch in 2.0.0 the sketch that replaced the SerialGateway.ino sketch from 1.5.4?
Second question: If so, is the GatewaySerial.ino sketch compatible with the Atmega32U4 based Arduino Micro (similar to the Arduino Leonardo)? Link to the arduino is below if you are not familiar with it.
@Nexus I see. I'm kinda thinking more and more that I may just switch to the arduino based serial gateway. It seems like there is more support for it in terms of keeping up with the mysensors development branch. I really liked the idea of just attaching the radio directly to the Raspi because I felt that it eliminated a potential point of failure but i'm probably wrong. Anyway this whole mysensors community is fantastic! Thanks for all of the hard work you guys do!
@emc2 Does this work with a serial connection? I have my radio connected directly to the SPI pins of the raspberry pi.
@mfalkvidd said:
The thread references by mvader above indicates that this is already solved though.
Wait, you mean there may already be a working version of PiSerialGateway out there? I hope that is the case and I'll check it out.
@Peter-Ε uΔΎaj I'm fairly new to this stuff, but curious if you are trying to auto-assign node ID? I don't believe the MySensorsBinding supports auto-assign so you have to define it as static and use:
#define NODEID 3 //or whatever
//and then call this in your setup instead of Sensor.begin();
Sensor.begin(NULL, NODEID);
in your script. Again, not sure if this is your problem but I figured I would chime in.
What would be involved in getting it working with 2.0? Are we talking modifying/writing a few new methods or is it closer to a full re-write of the entire application? I can put in some work but my coding skills are somewhat limited. I can however fight my way through it. I just recently became a very happy user of the PiSerialGateway and would hate to have to abandon it.
It is, I was going for maximum battery life so I was going to turn off everything while the micro controller was asleep. I'll try just using the built in sleep functionality.
My node is battery operated and as such I allow the micro controller to shut off power to all of the peripherals including the radio before it goes to sleep. Then when it wakes up it powers up the radio and sends its data before repeating the whole process from the beginning. As such I need to initialize the radio again after I power it back up. I saw that 2.0 has a feature like this but unfortunately I'm using the PiSerialGateway which doesn't support 2.0 so I am using 1.5.4. How can I manually re-initialize the radios upon each wake cycle? I've tried doing mysensors.begin but that does the entire presentation of the node to the gateway and controller. All I want to do is initialize the radio. Below is my current loop testing this out.
void loop()
{
sensor_node.send(msg.set(20));
digitalWrite(PER, HIGH); //turn off peripherals including radio
delay(5000); // Wait 5 seconds
digitalWrite(PER, LOW); //turn on peripherals including radio
sensor_node.begin(NULL, MY_NODE_ID); //this doesn't work...actually does too much
}```Oh! It's working again. I had used the stock eeprom clear sketch in the arduino id to reset my node and I should have used the eeprom clear config sketch in the mySensors examples within the mySensors arduino library to clear the eeprom. I couldn't get it to auto assign a node ID so I just hard coded one using:
gw.begin(NULL,3);
Then I updated my item to use that node id and voila:
2016-07-17 17:49:17.721 [DEBUG] [.b.m.internal.MySensorsBinding] - internalReceiveUpdate(Temperature,20) is called!
2016-07-17 17:49:17.723 [DEBUG] [.b.m.internal.MySensorsBinding] - Temperature = 20
It's a good day!
Checked the PiGatewaySerial.log file and nothing seems out of place. The log for today is simply:
Jul 17 15:38:13 raspberrypi PiGatewaySerial: Starting PiGatewaySerial...
Jul 17 15:38:13 raspberrypi PiGatewaySerial: Protocol version - 1.4
Jul 17 15:38:13 raspberrypi PiGatewaySerial: Created PTY '/dev/pts/0'
Jul 17 15:38:13 raspberrypi PiGatewaySerial: Gateway tty: /dev/ttyMySensorsGateway```Awwwww.....good feelings gone 
2016-07-17 15:50:54.019 [DEBUG] [.o.b.m.internal.gateway.Serial] - Error writing data on serial port /dev/ttyUSB20: Input/output error in writeArray
2016-07-17 15:50:54.021 [DEBUG] [.b.m.internal.MySensorsBinding] - Ping gateway: Faild, unable to contact gawatay
2016-07-17 15:50:54.026 [DEBUG] [.b.m.internal.MySensorsBinding] - Starting new gateway
2016-07-17 15:50:54.032 [ERROR] [.o.b.m.internal.gateway.Serial] - Unable to find Serial port '/dev/ttyUSB20'
I'm on an emotional roller coaster here. Now I'm back to:
2016-07-17 15:51:54.065 [ERROR] [.service.AbstractActiveService] - Error while executing background thread MySensors Refresh Service
java.lang.NullPointerException: null
at org.openhab.binding.mysensors.internal.gateway.Serial.write(Serial.java:82) ~[na:na]
at org.openhab.binding.mysensors.internal.MySensorsBinding.execute(MySensorsBinding.java:178) ~[na:na]
at org.openhab.core.binding.AbstractActiveBinding$BindingActiveService.execute(AbstractActiveBinding.java:156) ~[na:na]
at org.openhab.core.service.AbstractActiveService$RefreshThread.run(AbstractActiveService.java:173) ~[na:na]```OH MY GOSH!!! Just plugged in a node! It's alive! This is the best day of my life!!!
2016-07-17 15:50:05.345 [INFO ] [.b.m.internal.MySensorsBinding] - New MySensor node found: node-id=0
* Example item: 0;255;I_BATTERY_LEVEL - Use this to report the battery level 0-100 (%)
* Example item: 0;255;I_SKETCH_NAME - Sketch name that can be used to identify sensor
* Example item: 0;255;I_SKETCH_VERSION - Sketch version that can be reported to keep track of the version of sensor
Oh my gosh....I'm officially geeking out!
2016-07-17 15:42:54.396 [DEBUG] [.b.m.internal.MySensorsBinding] - Gateway Version: 1.4```Woo Hoo!!!!
2016-07-17 15:39:53.970 [DEBUG] [.o.b.m.internal.gateway.Serial] - Serial port '/dev/ttyUSB20' has been found.
Not sure what fixed it. I added pi and openhab to user group 'tty' and then rebooted. Okay baby steps here....moving on.
pi@raspberrypi:~ $ sudo adduser pi tty
Adding user `pi' to group `tty' ...
Adding user pi to group tty
Done.
pi@raspberrypi:~ $ sudo adduser openhab tty
Adding user `openhab' to group `tty' ...
Adding user openhab to group tty
Done.
Raspberry Pi3
Running openhab v1.8.3
nRF24L01+ connected directly to SPI of the Raspberry Pi using this instruction:
This gives me a serial gateway "ttyMySensorsGateway" and as the instructions specify I have a symbolic link between that and "ttyUSB20" (whatever that means....sorry new at some of this stuff):
ttyMySensorsGateway
ttyprintk
ttyS0
ttyUSB20
Next I followed this instruction:
https://forum.mysensors.org/topic/3108/openhab-binding
This is the result of all of this in the openhab debug log. What steps am I missing here?
2016-07-16 22:59:50.599 [DEBUG] [i.internal.GenericItemProvider] - Start processing binding configuration of Item 'Temperature (Type=NumberItem, State=Uninitialized)' with 'MySensorsGenericBindingProvider' reader.
2016-07-16 22:59:50.608 [DEBUG] [ySensorsGenericBindingProvider] - New Item "Temperature (Type=NumberItem, State=Uninitialized)" based on configuration "3;1;V_TEMP"
2016-07-16 22:59:50.609 [DEBUG] [i.internal.GenericItemProvider] - Start processing binding configuration of Item 'Temperature (Type=NumberItem, State=Uninitialized)' with 'MySensorsGenericBindingProvider' reader.
2016-07-16 22:59:50.610 [DEBUG] [ySensorsGenericBindingProvider] - New Item "Temperature (Type=NumberItem, State=Uninitialized)" based on configuration "3;1;V_TEMP"
2016-07-16 22:59:50.656 [DEBUG] [.b.m.internal.MySensorsBinding] - activate
2016-07-16 22:59:50.723 [ERROR] [.o.b.m.internal.gateway.Serial] - Unable to find Serial port '/dev/ttyUSB20'
2016-07-16 22:59:50.724 [INFO ] [.service.AbstractActiveService] - MySensors Refresh Service has been started
2016-07-16 22:59:50.728 [DEBUG] [inding.ntp.internal.NtpBinding] - Got time from ptbtime1.ptb.de: Saturday, 16 July 2016 22:59:50 o'clock UTC
2016-07-16 22:59:50.747 [ERROR] [.service.AbstractActiveService] - Error while executing background thread MySensors Refresh Service
java.lang.NullPointerException: null
at org.openhab.binding.mysensors.internal.gateway.Serial.write(Serial.java:82) ~[na:na]
at org.openhab.binding.mysensors.internal.MySensorsBinding.execute(MySensorsBinding.java:178) ~[na:na]
at org.openhab.core.binding.AbstractActiveBinding$BindingActiveService.execute(AbstractActiveBinding.java:156) ~[na:na]
at org.openhab.core.service.AbstractActiveService$RefreshThread.run(AbstractActiveService.java:173) ~[na:na]```I've been trying to get a mysensors node which is using an nRF24L01+ to transmit to a directly connected nRF24L01+ on a Raspberry Pi 3 running PiGatewaySerial. When I start the gateway I get
Starting PiGatewaySerial...
Protocol version - 1.4
Created PTY '/dev/pts/0'
Gateway tty: /dev/ttyMySensorsGateway
Following some other instruction I created a link to /dev/ttyUSB20 so that openhab could recognize it. I have Openhab with your serial binding in the addons folder. I am having difficulty with the binding. I feel like I have made a tiny bit of headway but it doesn't seem to be able to bind with it. In the openhab debug log I get:
2016-07-16 14:39:15.537 [ERROR] [.service.AbstractActiveService] - Error while executing background thread MySensors Refresh Service
java.lang.NullPointerException: null
at org.openhab.binding.mysensors.internal.gateway.Serial.write(Serial.java:82) ~[na:na]
at org.openhab.binding.mysensors.internal.MySensorsBinding.execute(MySensorsBinding.java:178) ~[na:na]
at org.openhab.core.binding.AbstractActiveBinding$BindingActiveService.execute(AbstractActiveBinding.java:156) ~[na:na]
at org.openhab.core.service.AbstractActiveService$RefreshThread.run(AbstractActiveService.java:173) ~[na:na]
What other information would you need to know to help me trouble shoot this?
EDIT: This has been solved. See here:
https://forum.mysensors.org/topic/4315/attempt-to-bind-ttymygatewayserial-to-openhab-failing-miserably
Has anyone successfully bound a mysensors node to a raspberry pi using PiGatewaySerial? I have an nRF24L01+ connected directly to the Pi through its SPI pins. I have the ttyMySensorsGateway running and have created a symbolic link to ttyUSB20. I just can't find an example of now binding it to openhab.
@sundberg84 Dang....now I'm really confused. I was under the impression that PIGatewaySerial handled assigning node id's and such. How would I find that out? I don't see a whole lot of documentation on this repository although I'm sure it exists......it seems pretty well built. The end result of all of this is to hopefully bind this serial connection to openhab. That's the goal at least.
@sundberg84 said:
@jerseyguy1996 - Do you have a controller behind the gateway? The req ID means the node is asking for a ID from the controller. It looks like the gateway recieves this request but there is no responce.
That's a good question. So when I run 'make all' on the mySensors Raspberry repository:
https://github.com/mysensors/Raspberry
I get two executables. There is the PiGatewaySerial and PiGateway. Do they both need to be running? I may have been under the mistaken impression that you could run one or the other. I'll give it a try.
@sundberg84 said:
@jerseyguy1996 - "st=fail" means the receiving node or gateway has problems sending ack back to the sending node.
Its probably a hardware issue (power and/or range). Try adding a capacitor (http://www.mysensors.org/build/connect_radio#connecting-a-decoupling-capacitor) to the receiving radio, change powersource, move receiver/sender closer to eachother or build a repeater.
Also if you are in the testface and have the node and gateway close to each other it can be the issue. If I only have a couple of meters it performce worse.
Thanks for responding! I do have capacitors on both the sending and receiving radios...soldered directly to the pins. It doesn't seem to be hardware as even prior to adding the capacitors the radio was transmitting and receiving reliably using the "gettingstarted" sketch in the RF24 library.
@AWI Thanks for responding! I wonder if there is a way to confirm that if nothing is actively receiving information from the gateway that it is off. The system definitely works fine when I use cat to redirect the serial gateway traffic to stdout.
pi@raspberrypi:~ $ sudo cat /dev/ttyUSB20
0;0;3;0;14;Gateway startup complete.
255;255;3;0;3;
255;255;3;0;3;
255;255;3;0;3;
255;255;3;0;3;
255;255;3;0;3;
255;255;3;0;3;
255;255;3;0;3;
255;255;3;0;3;
255;255;3;0;3;
255;255;3;0;3;
Prior to the redirect I get st=fail. Below is the serial monitor for the arduino sending.
send: 255-255-0-0 s=255,c=3,t=3,pt=0,l=0,sg=0,st=fail:
req id
send: 255-255-0-0 s=255,c=3,t=3,pt=0,l=0,sg=0,st=fail:
req id
send: 255-255-0-0 s=255,c=3,t=3,pt=0,l=0,sg=0,st=fail:
req id
send: 255-255-0-0 s=255,c=3,t=3,pt=0,l=0,sg=0,st=ok:
req id
send: 255-255-0-0 s=255,c=3,t=3,pt=0,l=0,sg=0,st=ok:
req id
send: 255-255-0-0 s=255,c=3,t=3,pt=0,l=0,sg=0,st=ok:
req id
send: 255-255-0-0 s=255,c=3,t=3,pt=0,l=0,sg=0,st=ok:
req id
send: 255-255-0-0 s=255,c=3,t=3,pt=0,l=0,sg=0,st=ok:
req id
send: 255-255-0-0 s=255,c=3,t=3,pt=0,l=0,sg=0,st=ok:
req id
send: 255-255-0-0 s=255,c=3,t=3,pt=0,l=0,sg=0,st=ok:
req id
send: 255-255-0-0 s=255,c=3,t=3,pt=0,l=0,sg=0,st=ok
So basically it fails a bunch of times and then once I start viewing it on the terminal its good from that point on. The only screwing thing about that is that if i'm not viewing it on the terminal, every so often (roughly 10% of the time) one of the transmissions will succeed. Definitely doesn't seem to be a hardware issue as the thing works great......as long as the serial gateway is redirected to the terminal.
Well the pictures don't seem to show up.
These links should work. The pictures in order:
Okay that subject could probably use some work but hopefully I can explain things. I have a Raspberry PI 3 running PiGatewaySerial, and I have an arduino running the BinarySwitchSensor example code. When I first started the code I was getting ST=Fail about 90 percent of the time.
The image shows the serial monitor for the arduino on the right side of the picture and the terminal window for the Raspberry Pi on the left.
Just to check the operation of the radios I ran the "gettingstarted" sketch in the RF24 library on both the raspberry pi and the arduino. The picture below shows that the radios are purring along like a kitten. No missed transmissions.
On a whim I decided to view the output of the ttyMySensorsGateway while the PiGatewaySerial process was running and suddenly it started working. What's more whacky, if I stopped watching the ttyMySensorsGateway it would start missing transmissions again. Then when I started watching it would start working.
I don't know nearly enough about the inner workings of the library to know where to even begin figuring out the source of this behavior. Any hints as to why it might be doing this?
make file has changes and there is no more librf24-bcm. Refer to the readme on the git and follow them
Re: [Tutorial] Raspberry Pi NRF24l01 direct connection
The GIT library has changed. You will need to "cd Raspberry" and then sudo git clone https://github.com/TMRh20/RF24
cd RF24 and make all and sudo make install
next cd .. and sudo make all and sudo make install