💬 Building a Raspberry Pi Gateway
@masmat I did a test with the following configuration:
Raspberry Pi 1 with Raspbian (2017-11-29-raspbian-stretch-lite)
pi@raspberrypi:~/MySensors $ lsb_release -a No LSB modules are available. Distributor ID: Raspbian Description: Raspbian GNU/Linux 9.1 (stretch) Release: 9.1 Codename: stretch
MySensors master branch - Protocol version - 2.2.0
./configure --my-transport=nrf24 --my-gateway=mqtt --my-controller-ip-address=127.0.0.1 --my-mqtt-publish-topic-prefix=mysensors-out --my-mqtt-subscribe-topic-prefix=mysensors-in --my-mqtt-client-id=m ygateway1 --my-mqtt-user=rpi --my-mqtt-password=password
Mosquitto version 1.4.10 (build date Fri, 22 Dec 2017 08:19:25 +0000) [installed from apt-get]
pi@raspberrypi:~/MySensors $ cat /etc/mosquitto/mosquitto.conf # Place your local configuration in /etc/mosquitto/conf.d/ # # A full description of the configuration file is at # /usr/share/doc/mosquitto/examples/mosquitto.conf.example pid_file /var/run/mosquitto.pid persistence true persistence_location /var/lib/mosquitto/ log_dest file /var/log/mosquitto/mosquitto.log allow_anonymous false password_file /etc/mosquitto/passwordfile include_dir /etc/mosquitto/conf.d
Added the mosquitto user (user=rpi, password=password) with:
sudo mosquitto_passwd -c /etc/mosquitto/passwordfile rpi
It didn't show any error to connect to the MQTT broker:
pi@raspberrypi:~/MySensors $ sudo ./bin/mysgw -d mysgw: Starting gateway... mysgw: Protocol version - 2.2.0 mysgw: MCO:BGN:INIT GW,CP=RNNGL---,VER=2.2.0 mysgw: TSF:LRT:OK mysgw: TSM:INIT mysgw: TSF:WUR:MS=0 mysgw: TSM:INIT:TSP OK mysgw: TSM:INIT:GW MODE mysgw: TSM:READY:ID=0,PAR=0,DIS=0 mysgw: MCO:REG:NOT NEEDED mysgw: MCO:BGN:STP mysgw: MCO:BGN:INIT OK,TSP=1 mysgw: GWT:RMQ:MQTT RECONNECT mysgw: connected to 127.0.0.1 mysgw: GWT:RMQ:MQTT CONNECTED mysgw: GWT:TPS:TOPIC=mysensors-out/0/255/0/0/18,MSG SENT mysgw: TSF:MSG:READ,5-5-0,s=255,c=3,t=24,pt=1,l=1,sg=0:1 mysgw: TSF:MSG:PINGED,ID=5,HP=1 mysgw: TSF:MSG:SEND,0-0-5-5,s=255,c=3,t=25,pt=1,l=1,sg=0,ft=0,st=OK:1 mysgw: TSF:MSG:READ,5-5-0,s=255,c=3,t=32,pt=5,l=4,sg=0:500 mysgw: GWT:TPS:TOPIC=mysensors-out/5/255/3/0/32,MSG SENT mysgw: TSF:MSG:READ,5-5-0,s=255,c=3,t=33,pt=5,l=4,sg=0:4951 mysgw: GWT:TPS:TOPIC=mysensors-out/5/255/3/0/33,MSG SENT mysgw: TSF:MSG:READ,5-5-0,s=1,c=1,t=37,pt=4,l=4,sg=0:36053 mysgw: GWT:TPS:TOPIC=mysensors-out/5/1/1/0/37,MSG SENT mysgw: TSF:MSG:READ,5-5-0,s=255,c=3,t=32,pt=5,l=4,sg=0:500 mysgw: GWT:TPS:TOPIC=mysensors-out/5/255/3/0/32,MSG SENT mysgw: TSF:MSG:READ,5-5-0,s=255,c=3,t=33,pt=5,l=4,sg=0:5000 mysgw: GWT:TPS:TOPIC=mysensors-out/5/255/3/0/33,MSG SENT mysgw: TSF:MSG:READ,5-5-0,s=1,c=1,t=37,pt=4,l=4,sg=0:36055 mysgw: GWT:TPS:TOPIC=mysensors-out/5/1/1/0/37,MSG SENT mysgw: TSF:MSG:READ,5-5-0,s=255,c=3,t=32,pt=5,l=4,sg=0:500 mysgw: GWT:TPS:TOPIC=mysensors-out/5/255/3/0/32,MSG SENT mysgw: TSF:MSG:READ,5-5-0,s=255,c=3,t=33,pt=5,l=4,sg=0:5000 mysgw: GWT:TPS:TOPIC=mysensors-out/5/255/3/0/33,MSG SENT mysgw: TSF:MSG:READ,5-5-0,s=1,c=1,t=37,pt=4,l=4,sg=0:36055 mysgw: GWT:TPS:TOPIC=mysensors-out/5/1/1/0/37,MSG SENT
mvader last edited by
@masmat have you tried with ethernet gateway? If I have time I'll try the mqtt this weekend
@mvader I never noticed that.... is it the mqtt GW?
I'm not using mqtt.
for debug purposes i use MYSController
every 10 seconds on the dot. it shows me the version of the gateway.
201 3/15/2018 20:47:15 RX 0 - Gateway INTERNAL C_INTERNAL NO I_VERSION 2.2.0 202 3/15/2018 20:47:25 RX 0 - Gateway INTERNAL C_INTERNAL NO I_VERSION 2.2.0 203 3/15/2018 20:47:35 RX 0 - Gateway INTERNAL C_INTERNAL NO I_VERSION 2.2.0 204 3/15/2018 20:47:45 RX 0 - Gateway INTERNAL C_INTERNAL NO I_VERSION 2.2.0 205 3/15/2018 20:47:55 RX 0 - Gateway INTERNAL C_INTERNAL NO I_VERSION 2.2.0 206 3/15/2018 20:48:05 RX 0 - Gateway INTERNAL C_INTERNAL NO I_VERSION 2.2.0
@marceloaqno any ideas about that?
@mvader oh, that's normal. I though you meant something else
otto001 last edited by otto001
Yesterday I cloned the latest version on a recent raspbian (9.3) and I applied the first patch of @marceloaqno .
We will see. So long there were no problems. I will send an update in a few days...
As a last help I could switch to mqtt and do a restart after a defined amount of time (if no events are received)....
@marceloaqno I got my gw rfm69 gateway suddenly stopped communicating with nodes. I tried everything to reinstall it but without luck. I was able to have it running on my test rpi with a complete OS reinstall. Is there anything else I need need to clean up from my install to reset every settings? (besides the mysensors folder and mysensors.dat file I already deleted)
romeo01 last edited by
How can I monitor the traffic data between the raspberry and RF module (NRF24L01) on a Ethernet gateway ??
My gateway is built for Ethernet. I start the gateway with "service mysgw start"
Now, I would like to get the same data output than output debug (./bin/mysgw -d) but without stop mysgw service.
I need to use MYSController as Ethernet client at the same time.
@romeo01 see instructions at https://www.mysensors.org/build/raspberry#troubleshooting
@marceloaqno What does your mosquitto.log show?
I did a fresh install of DietPi (stretch), Mosquitto and MySensors --branch master. I left out everything and pretty much did the configure command as you did. I get the same result, but mosuiqtto log shows:
1521584708: New connection from 127.0.0.1 on port 1883. 1521584708: New client connected from 127.0.0.1 as mygateway1 (c1, k15, u'masi'). 1521584733: Socket error on client mygateway1, disconnecting. 1521584778: New connection from 127.0.0.1 on port 1883.
So is this normal?
I have one sensors built that's not connecting (its log shows it just trying and trying..). I would like to user simple password and the LEDs, I will build one extra sensors just to help testing.
otto001 last edited by otto001
@MasMat : what does your mysgw.log show?
romeo01 last edited by
@mfalkvidd Thanks fer info, now I can see the serial protocol as well in the syslog. Next step should be to have a logfile dedicated to mysgw.
Mar 21 20:06:05 DietPi systemd: Started MySensors Gateway daemon. Mar 21 20:06:05 DietPi mysgw: Starting gateway... Mar 21 20:06:05 DietPi mysgw: Protocol version - 2.2.0 Mar 21 20:06:05 DietPi mysgw: MCO:BGN:INIT GW,CP=RNNGL---,VER=2.2.0 Mar 21 20:06:05 DietPi mysgw: TSF:LRT:OK Mar 21 20:06:05 DietPi mysgw: TSM:INIT Mar 21 20:06:05 DietPi mysgw: TSF:WUR:MS=0 Mar 21 20:06:05 DietPi mysgw: TSM:INIT:TSP OK Mar 21 20:06:05 DietPi mysgw: TSM:INIT:GW MODE Mar 21 20:06:05 DietPi mysgw: TSM:READY:ID=0,PAR=0,DIS=0 Mar 21 20:06:05 DietPi mysgw: MCO:REG:NOT NEEDED Mar 21 20:06:05 DietPi mysgw: MCO:BGN:STP Mar 21 20:06:05 DietPi mysgw: MCO:BGN:INIT OK,TSP=1 Mar 21 20:06:05 DietPi mysgw: GWT:RMQ:MQTT RECONNECT Mar 21 20:06:05 DietPi mysgw: connected to 127.0.0.1 Mar 21 20:06:05 DietPi mysgw: GWT:RMQ:MQTT CONNECTED Mar 21 20:06:05 DietPi mysgw: GWT:TPS:TOPIC=mysensors-out/0/255/0/0/18,MSG SENT
Where is mysgw.log?
otto001 last edited by
@MasMat : I just forgot, that I reconfigured rsyslogd to log mysgw to a different file. syslog is correct.
I do not use mqtt for mysensors yet, but the syslog seems good?
Richard van der Plas last edited by
Was pointed here from another post, having serious issues with high CPU utilization op the gateway, is there any workaround and the moment?
asks: 157 total, 2 running, 155 sleeping, 0 stopped, 0 zombie %Cpu(s): 2.5 us, 23.0 sy, 0.0 ni, 74.3 id, 0.1 wa, 0.0 hi, 0.0 si, 0.0 st KiB Mem : 949580 total, 448732 free, 146912 used, 353936 buff/cache KiB Swap: 102396 total, 102396 free, 0 used. 737656 avail Mem PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 337 root 20 0 20492 1060 932 R 100.0 0.1 28:54.55 mysgw 3947 pi 20 0 8248 3324 2736 R 1.6 0.4 0:00.82 top 447 homeass+ 20 0 340112 63684 9916 S 1.0 6.7 3:28.71 hass 7 root 20 0 0 0 0 S 0.3 0.0 0:04.18 rcu_sched 767 root 20 0 126572 8628 6544 S 0.3 0.9 0:00.95 piplight-daemon
PRETTY_NAME="Raspbian GNU/Linux 9 (stretch)" NAME="Raspbian GNU/Linux" VERSION_ID="9" VERSION="9 (stretch)" Linux raspberrypi 4.9.59-v7+ #1047 SMP Sun Oct 29 12:19:23 GMT 2017 armv7l GNU/Linux
Rebooting the pi sometimes helps, sometimes freezes the pi
seeing nothing strange in the mysensors log what so ever
running MySensors Version 2.2.0
and Home Assistant Version 0.64.0
Anyone can point me in the direction where to troubleshoot this further ?
its not a high traffic gateway (around 10 sensors connected of which 5 updating every 15 minutes)
@richard-van-der-plas the best workaround so far is in the post I linked to.
@mvader The gateway will respond with an I_VERSION every time a controller connected to port 5003 sends an I_VERSION request.
@gohan Sorry to hear that, mysgw doesn't change any system files, a simple reboot and rebuild of the gateway should be enough to resume communication in a case of more serious error.
@masmat This is my mosquitto.log
1521680648: mosquitto version 1.4.10 (build date Fri, 22 Dec 2017 08:19:25 +0000) starting 1521680648: Config loaded from /etc/mosquitto/mosquitto.conf. 1521680648: Opening ipv4 listen socket on port 1883. 1521680648: Opening ipv6 listen socket on port 1883. 1521762617: Saving in-memory database to /var/lib/mosquitto/mosquitto.db. 1521763549: New connection from 127.0.0.1 on port 1883. 1521763549: New client connected from 127.0.0.1 as mygateway1 (c1, k15, u'rpi').
A socket error message:
1521764339: Socket error on client mygateway1, disconnecting.
shows only if I stop/exit mysgw.
@marceloaqno OK, I will look into that once I have an extra sensor feeding my gw (the one I built is a little complex and could be buggy).
Another question: I configured mysgw without "simple password" to sort out problems.
Now to reconfigure mysgw I have to run the "./configure --blah --blahblah..." command and "make", but do I also have to do "make install"? And do I have to re-start & enable the service? Should I stop it first also? Anybody got a step-by-step for this?
You could also make a simple node running mock mysensors sketch that can simulate a working sensor, if you need some data running through the gateway. When I recompile the gateway I usually stop the service, uninstall the mysgw service and do the make and make install. I don't really know if it is actually required but I like to keep things clean
The two patches to fix ethernet stability have been merger into the development branch, and also some changes to the gateway logging. I updated the build instructions to reflect the changes.
@gohan I made a sensor that sends DHT11 temp+hum. This is the output (some of it..) from mosquitto_sub to topic mysensors-out. So I appear to have a something working. OpenHab2 is not finding any items still...
pi@DietPi:~ $ mosquitto_sub -u XXXXXX -P YYYYYY -v -t 'mysensors-out/#' mysensors-out/99/1/1/0/0 14.0 mysensors-out/99/0/1/0/1 46.0 mysensors-out/99/1/1/0/0 15.0 mysensors-out/99/0/1/0/1 45.0 mysensors-out/99/1/1/0/0 15.0 mysensors-out/99/0/1/0/1 45.0 mysensors-out/99/0/1/0/1 44.0 mysensors-out/99/0/1/0/1 45.0 mysensors-out/99/0/1/0/1 44.0 mysensors-out/99/1/1/0/0 15.0 mysensors-out/99/0/1/0/1 45.0 mysensors-out/99/1/1/0/0 15.0 mysensors-out/99/0/1/0/1 44.0 mysensors-out/99/0/1/0/1 45.0 mysensors-out/99/0/1/0/1 44.0 mysensors-out/99/1/1/0/0 15.0 mysensors-out/99/0/1/0/1 44.0 mysensors-out/99/1/1/0/0 15.0
Once I changed the config to include simple password, it's not showing anything anymore in mosquitto_sub
It would appear that something is missing from my setup or there's a bug in the configure-line. Can someone tell if there's a bug here somewhere:
sudo ./configure --my-transport=nrf24 --my-rf24-irq-pin=15 --my-signing=password --my-signing-password=ZZZZZZ --my-gateway=mqtt --my-controller-ip-address=127.0.0.1 --my-mqtt-user=XXXXXX --my-mqtt-password=YYYYYY --my-mqtt-publish-topic-prefix=mysensors-out --my-mqtt-subscribe-topic-prefix=mysensors-in --my-mqtt-client-id=mygateway1 --my-leds-err-pin=12 --my-leds-rx-pin=16 --my-leds-tx-pin=18
Look also in node log, that's the first place to look at
@gohan I did, I will post it (but it appears to send normally). But the only things I changed was:
- Rpi configure added: --my-signing=password --my-signing-password=ZZZZZZ
- In the nodes code: #define MY_SIGNING_SIMPLE_PASSWD = "ZZZZZZ"
I use also these parameters with the normal signing
--my-signing=software --my-signing-request-signatures --my-signing-weak_security --my-signing-debug
of course the debug parameter is there only for debug reasons
@masmat check that the version you are using (release or beta) match your use of the simple flags, as they differ at the moment.
@anticimex Both Arduino IDE is 2.2 and Rpi is compiled with 2.2 stable.
I'm seeing !TSF:MSG:SIGN FAIL in the serial monitor so something is not compatible... I will try making password >8 characters next (currently 6).
I will also add those parameters to see if that makes a difference before reuploading arduino code
@masmat if you add the signing debug flag and use the log parser on the homepage it should become clear what the problem is. You can also use the troubleshooting guide in the signing documentation.
@anticimex This is what's happening in the gw:
The parser didn't really help much: more baffled than before....and I came away from the troubleshooting guide feeling really stupid
@masmat looks to me that your gateway is not set up for signing
@anticimex I think he didn't use all the parameters for the configure, right?
@gohan the simple flags should not need more args, but I don't use a rPi as gw so I honestly am not sure exactly the args to use. The beta documentation has clear instructions for rPi signing, but those are specifically for beta branch and probably don't map exactly to the release yet.
@gohan The whole configure-line:
sudo ./configure --my-transport=nrf24 --my-rf24-irq-pin=15 --my-signing=software --my-signing-request-signatures --my-signing-weak_security --my-signing-debug --my-signing=password --my-signing-password=ZZZZZZ --my-gateway=mqtt --my-controller-ip-address=127.0.0.1 --my-mqtt-user=XXXX --my-mqtt-password=YYYYY --my-mqtt-publish-topic-prefix=mysensors-out --my-mqtt-subscribe-topic-prefix=mysensors-in --my-mqtt-client-id=mygateway1 --my-leds-err-pin=12 --my-leds-rx-pin=16 --my-leds-tx-pin=18
If anyone can tell what's missing or if there's a typo?
@masmat you have redundant flags. The password option require no other signing flags. Only if you select software as signing backend you need other options (and none of the simple flags)
And remember that if you use software signing and not password signing, you need to personalize the GW and/or node.
@anticimex I thought so too, but I'm grasping at straws to get the signing to work.
To clarify, is the following enough for simple signing: --my-signing-debug --my-signing=password --my-signing-password=ZZZZZZ
And the arduino code #define MY_SIGNING_SIMPLE_PASSWD = "ZZZZZZ"
Any difference where it's placed in the code? Anything else to check for?
@masmat it needs to be defined prior to the inclusion of mysensors.h. That should be it. (on the arduino node that is).
While on the subject: what would be the flags needed for setting the gateway to only use the simple encryption but not the (simple) signing feature?
I looked in the documentation and the node commands aren't mirrored for the gateway. I was hoping for something like:
It's actually not needed since you can still set signing as optional on gateway
@alowhum that feature is still only available for beta and is documented here: https://www.mysensors.org/apidocs-beta/group__SecuritySettingGrpPub.html
EDIT: not yet for rPi
Pull requests are welcome. I don't have time for this at the moment.
Right. So is this correct?
NODES (arduino nano)
On all my nodes I will update them to have this code at the top:
#define MY_ENCRYPTION_SIMPLE_PASSWD spiderman41 // unfortunately Nano hardware doesn't really have enough memory for signing.
#define MY_RF24_CHANNEL 100 // in EU the default channel 76 overlaps with wifi.
#define MY_RF24_DATARATE RF24_1MBPS // slower datarate makes the network more stable?
GATEWAY (Raspberry Pi Zero W)
On my gateway I will use this configure code:
@alowhum you will need to enable weak security as well as that will enable both signing and encryption with signature requirements from all nodes on the gw
as that will enable both signing and encryption with signature requirements from all nodes on the gw
But I don't want signing? Or do you mean that it will remove that requirement?
I only need to set that on the gateway, right?
I've also added a slower datarate, thinking that will also create a more stable connection. I am in a busy urban environment with lots of RF noise. Is that smart?
@alowhum I thought you did not want signing: "but not the (simple) signing feature?"
Yes, I don't want signing. But what you wrote said that it wil ENABLE signing. Check your sentence. Probably a typo, but I wanted to make sure
@alowhum the simple security flag enables signing yes.
But does the "--my-signing-weak_security" enable signing?
I want to disable signing completely. What flags do I need to use when building a gateway that only uses encryption?
@alowhum just don't use any flags mentioning signing, personalize the gw according to the documentation and pick the appropriate encryption flag.
@anticimex I've built a new node, DHT11 that sends temp&hum data. I reconfigured Rpi with this:
sudo ./configure --my-transport=nrf24 --my-rf24-irq-pin=15 --my-signing-debug --my-signing=password --my-signing-password=XXXXXX --my-gateway=mqtt --my-controller-ip-address=127.0.0.1 --my-mqtt-user=YYYY --my-mqtt-password=ZZZZZ --my-mqtt-publish-topic-prefix=mysensors-out --my-mqtt-subscribe-topic-prefix=mysensors-in --my-mqtt-client-id=mygateway1 --my-leds-err-pin=12 --my-leds-rx-pin=16 --my-leds-tx-pin=18
This is what I get in gw syslog:
Apr 2 22:53:11 DietPi mysgw: Starting gateway... Apr 2 22:53:11 DietPi mysgw: Protocol version - 2.2.0 Apr 2 22:53:11 DietPi mysgw: MCO:BGN:INIT GW,CP=RNNGLSQX,VER=2.2.0 Apr 2 22:53:11 DietPi mysgw: !SGN:BND:PWD<8 Apr 2 22:53:11 DietPi mysgw: !SGN:INI:BND FAIL Apr 2 22:53:11 DietPi mysgw: TSF:LRT:OK Apr 2 22:53:11 DietPi mysgw: TSM:INIT Apr 2 22:53:11 DietPi mysgw: TSF:WUR:MS=0 Apr 2 22:53:11 DietPi mysgw: TSM:INIT:TSP OK Apr 2 22:53:11 DietPi mysgw: TSM:INIT:GW MODE Apr 2 22:53:11 DietPi mysgw: TSM:READY:ID=0,PAR=0,DIS=0 Apr 2 22:53:11 DietPi mysgw: MCO:REG:NOT NEEDED Apr 2 22:53:11 DietPi mysgw: MCO:BGN:STP Apr 2 22:53:11 DietPi mysgw: MCO:BGN:INIT OK,TSP=1 Apr 2 22:53:11 DietPi mysgw: GWT:RMQ:MQTT RECONNECT Apr 2 22:53:11 DietPi mysgw: connected to 127.0.0.1 Apr 2 22:53:11 DietPi mysgw: GWT:RMQ:MQTT CONNECTED Apr 2 22:53:11 DietPi mysgw: GWT:TPS:TOPIC=mysensors-out/0/255/0/0/18,MSG SENT Apr 2 22:53:23 DietPi mysgw: TSF:MSG:READ,99-99-255,s=255,c=3,t=7,pt=0,l=0,sg=0: Apr 2 22:53:23 DietPi mysgw: TSF:MSG:BC Apr 2 22:53:23 DietPi mysgw: TSF:MSG:FPAR REQ,ID=99 Apr 2 22:53:23 DietPi mysgw: TSF:PNG:SEND,TO=0 Apr 2 22:53:23 DietPi mysgw: TSF:CKU:OK Apr 2 22:53:23 DietPi mysgw: TSF:MSG:GWL OK Apr 2 22:53:23 DietPi mysgw: SGN:SKP:MSG CMD=3,TYPE=8 Apr 2 22:53:23 DietPi mysgw: TSF:MSG:SEND,0-0-99-99,s=255,c=3,t=8,pt=1,l=1,sg=0,ft=0,st=OK:0 Apr 2 22:53:25 DietPi mysgw: TSF:MSG:READ,99-99-0,s=255,c=3,t=24,pt=1,l=1,sg=0:1 Apr 2 22:53:25 DietPi mysgw: SGN:SKP:MSG CMD=3,TYPE=24 Apr 2 22:53:25 DietPi mysgw: TSF:MSG:PINGED,ID=99,HP=1 Apr 2 22:53:25 DietPi mysgw: SGN:SKP:MSG CMD=3,TYPE=25 Apr 2 22:53:25 DietPi mysgw: TSF:MSG:SEND,0-0-99-99,s=255,c=3,t=25,pt=1,l=1,sg=0,ft=0,st=OK:1 Apr 2 22:54:18 DietPi mysgw: TSF:MSG:READ,99-99-0,s=1,c=3,t=16,pt=0,l=0,sg=0: Apr 2 22:54:18 DietPi mysgw: SGN:SKP:MSG CMD=3,TYPE=16 Apr 2 22:54:18 DietPi mysgw: !SGN:NCE:GEN Apr 2 22:54:23 DietPi mysgw: TSF:MSG:READ,99-99-0,s=0,c=3,t=16,pt=0,l=0,sg=0: Apr 2 22:54:23 DietPi mysgw: SGN:SKP:MSG CMD=3,TYPE=16 Apr 2 22:54:23 DietPi mysgw: !SGN:NCE:GEN
This is kicking my butt... I cant understand that last part about the nonce
I will add the code from the node as soon as possible.
@masmat and this
Means the signing backend failed to initialize. So you need to make the password longer.
@mfalkvidd Made the password 10 characters. From looks of the logs, it's working now.
I cant believe I skipped the step of making the password longer... Just got too fixated on the password I came up with.
@masmat the nonce failures is because the backend never initialized so basically any call to the backend that can fail will fail.
I just discovered these USB-to-NRF24 devices. Would it be possible to use that instead of connecting to the GPIO pins?
@alowhum not with the existing code. Is there a datasheet that describes how these modules work?
One of the reviews says "have no idea wath software to use with this" so documentation might be hard to come by.
Background: I use signing software on some nodes + whitelisting on a node (of course only PI serial is on the whitelist).
With current --development branch (I think 2.3.0alpha) I cannot anymore set my previous personalized flags on gateway RPI3.
In detail, with current master (2.2.0) I can do:
sudo mysgw --set-soft-hmac-key=F618D4[...]848992B sudo mysgw --set-soft-serial-key=26[...]9 sudo mysgw --set-aes-key=EC7[...]CEB4
WIth development I did see only the
--get[...]flags and cannot set anymore. Can you confirm?
How can I set my previous values for signing?
@sineverba I believe this change alters how rPi port handles signing related personalisation: https://github.com/mysensors/MySensors/commit/3c0b2727a56907277d4d04c985fd72b14e4a483c
And, as usual, the documentation is a good place to start https://www.mysensors.org/apidocs-beta/group__MySigninggrpPub.html#MySigninggrphowuse
I'm currently compiling the code for connecting the NRF24l01+ directly to the Raspberry PI. Since I'm running the controller (on this case OpenHab) on the same Raspberry PI, would it be recommended the Ethernet or the serial flavor of it?
In the case of ethernet, can I place the own machine IP (127.0.0.1)? This way, if I need to change the IP address of the PI it wouldn't affect the communication between the controller and the MySensors code, right?
And by the way, for the signing configuration, it is mentioned in the documentation "Update the gateway config file with the generated keys/valeus", what file is that (name, path)?
I should be able to re-use the keys I have defined before, right? So I just go to step 2 (no need to generate new keys).
I'm refering to this link.
--my-controller-url-address=127.0.0.1 is not needed for ethernet
I found that the configuration file is /etc/mysensors.conf but " The first time you start the gateway the configuration file will be created if it does not already exist.", so that's why I wasn't finding it.
Anyway, the file states that:
"Note: The gateway must have been built with signing support to use the options below."
What flags should I include to have signing support?
OK, found it: just run ./configure -h and there is a list of options. Leaving it here just for future reference
ust run ./configure -h and there is a list of options. Leaving it here just for future reference
it is already written in the article
joaoabs last edited by
Thanks for the replies.
I've changed the PI from a PI1 to a PI3 and was able to make it working with signing. Its running smoothly, I guess the GW is chosen :).
I'll now focus on the nodes, specially the SenseBender micros that are 2xAA battery powered and are consuming ~3% bat per day, but that will be for another post...
Hi, is there any way to check the current gateway operating parameters? My purpose is to check the radio channel and power level set before compilation but I would be glad if I could check other configurable parameters. I looked at Makefile.inc and found some flags set, but not the information I was looking for (does it mean that the default values are set)? Debug logs neither provide these informations.
What radio are you using?
@gohan nrf24, one deployment pa+lna version with external antenna and the other standard with build-in "zig-zag" antenna.
I always set gw to max power if the radio is shielded
Is it normal to have frequently these errors in the RPI GW?
May 11 00:43:54 nettemp mysgw: RF24: Recovered from a bad interrupt trigger. May 11 00:43:54 nettemp mysgw: RF24: Recovered from a bad interrupt trigger. May 11 00:43:56 nettemp mysgw: RF24: Recovered from a bad interrupt trigger. May 11 00:43:56 nettemp mysgw: RF24: Recovered from a bad interrupt trigger. May 11 00:43:58 nettemp mysgw: RF24: Recovered from a bad interrupt trigger. May 11 00:43:58 nettemp mysgw: RF24: Recovered from a bad interrupt trigger. May 11 00:44:00 nettemp mysgw: RF24: Recovered from a bad interrupt trigger. May 11 00:44:00 nettemp mysgw: RF24: Recovered from a bad interrupt trigger.
@gohan Well, that is not an answer to my question apparently I suppose that max power lever is the default setting according to the configure script's help.
also look for a channel outside the WiFi range
kberck3 last edited by
Openhab2 on pi3b+ using nrf24 radios and mqtt. I can follow the wiring diagram, but the commands are a bit confusing and seem to jump around randomly. Do I put all the --my-blah-blah together after the ./configure to build a file? Should I do development version? Do the nfr improvements go together with everything else?
Do I put all the --my-blah-blah together after the ./configure to build a file?
From the article "Note: All options must be added to the same line, after ./configure"
Leave the development version for now, the stable works fine.
@gohan to be fair, I added that note this morning so kberck3 might not have seen it
kberck3 last edited by
Appreciate the reply mfalkvidd and gohan! Service is running, will report back if I run into other issues.
Mark Swift last edited by
Is anyone here using the Pi with OTA updates? I'm finding them painfully slow (1-2 stream messages every few seconds). It's taking 1 hour per OTA update compared with 2-3 minutes when using the Arduino gateway!
I did some tests on pi3 and I found slow ota too. Tekka has an open issue on github about this.
I tried to setup my Raspberry running Node-RED and serial gateway but I got stuck halfway. I followed the serial gateway compilation above and got it up and running, however using the serial nodes an Node-RED I could not manage to get them to connect tho the gateway.
First I tried to connect to
/dev/ttyMySensorsGatewaywhich did not work due to permissions (owned by root). When checking out
/dev/ttyMySensorsGatewayI found it links to
which belongs to root and the tty group. But I could not connect to this as the tty group only has write privileges. I think I miss some crucial point connecting those two together so I hope somebody can save the day by pointing me in the right direction.
Thanks in advance,
So you run a separate arduino board as a mysensors gateway, connected with serial (USB) to your raspberry pi? Or do you mean that you are using the rpi directly with radio, and then run the rpi variant of the mysensors gateway code?
@tbowmo I run the gateway on my Pi directly with the radio is connected to the Pi's GPIOs. Compilation and gateway do just fine I, if only I could convince my Pi to let Node-RED talk to the device
This is my output:
dietpi@buddy:~ $ ll /dev/ttMySensorsGateway lrwxrwxrwx 1 root root 10 Jun 18 14:38 /dev/ttMySensorsGateway -> /dev/pts/2 dietpi@buddy:~ $ ll /dev/pts/ total 0 crw--w---- 1 dietpi tty 136, 0 Jun 18 14:38 0 crw--w---- 1 dietpi tty 136, 1 Jun 18 14:38 1 crw--w---- 1 root tty 136, 2 Jun 18 14:38 2 crw--w---- 1 dietpi tty 136, 3 Jun 18 14:38 3 c--------- 1 root root 5, 2 Nov 3 2016 ptmx
wasn't it the problem of the missing permission on the dialup group?
Unfortunately adding my nodered user to dialout did not bring the hoped success. I still get premission denied messages after a reboot of my raspberry.
As my console print above shows the
/dev/ptsdevice belongs to tty but adding nodered to tty did not work out either (since the group only has write privileg). I have no idea how to fix this other then chowning the port to nodered but that feels wrong for me after years using linux based systems.
it is not a solution, but you could switch to ethernet GW and you will avoid all the permissions problems.
My 5 cents:
Run it as a MQTT gateway, if possible. It makes things so much easier, when you interact with the data in node-red. Even integrating other controllers is easier, as you have the MQTT as standard backbone bus between everything.
You need to have a MQTT broker (mosquitto) running as well.. But it's worth it..
Yes I came to the conclusion that this might be my only option even if it sucks as I have to subscribe to all events from MySensors, process them with Node-RED and republish again which screws my logging a bit. Right now I have another flow subscribed to "#" and write every event into my DB.
Since I have everything talking to mosquitto setup to follow Homie Convention I was hoping for only having my MQTT broker bombarded with compliant messages and have Node-RED convert everything (assign device names, etc. using a SQLite DB) from serial so the rather cryptic MySensors topics do not show up there.
@mirodin you actually need only mysensors-in and mysensors-out topics and their subtopics
@gohan Yes I know but now I can no longer just wildcard-dump every event on my mosquitto instance into my DB as I need to filter out the mysensor-in and -out topics.
Or meanwhile just use the ethernet gw
Well... I think I fixed it, let's hear it for documentation. Just when I had MQTT setup half way I got struck by the idea that there was some group flag for
configure. And indeed there is, setting
--my-serial-groupname=nodereddid the trick making
/dev/pts/Xowned by group nodered and let Node-RED connect to it, writing and reading works just fine now.
Thanks @gohan for your input I think I would have gone the ethernet route in the end if this last test had failed.
Inso last edited by
I am currently trying to update to 2.3
Have stopped service and deleted the file (systemctl status mysgw -> Unit mysgw.service could not be found.)
Also renamed the config file /etc/mysensors.dat
Renamed the old folder, then copied new files.
Checked readme.md in MySensors-folder: MySensors Library v2.3.0
Then I configured the radio and -> make, no errors
However, changing to bin folder and executing mysgw shows: Protocol 2.2.0
What am I missing?
@inso Did you
sudo make installafter building it? This command copies the service file and mysgw to their respective locations.
@inso remember to unregister the service and then make a new make install of the new gw
@gohan how is the unregistration done? I didn’t know that was needed. We should probably add upgrade instructions to the build page.
Inso last edited by
make install before testing did the trick, now it is 2.3.0 .
Was just going step by step through tutorial, there it´s make -> test -> make install. Didn´t realized it would use old parts if it´s not first install
thought stop, disable and remove the service would be enough to ensure the service is completely "uninstalled" - could you give me a hint what I´ve missed?
ricorico94 last edited by ricorico94
I try to access log info from my gateway installed on my domoticz raspberry pi, but I get no success..
First, I can't find the mysensors.conf file : nothing in the /etc folder. I tried to use "find / -name 'mysensors.conf' 2>/dev/null" command, but it finds nothing.
I tried creating such a file (then it's found by the fond command above) and in which I have the lines
as instructed above.
I restarted the wole Raspberry PI, then tried the command cat /tmp/mysgw.pipe but error message:
cat: /tmp/mysgw.pipe: Aucun fichier ou dossier de ce type
(= no file or folder like that)
I then tried this: sudo mysgw -c /etc/mysensors.conf and I got also error message:
mysgw: invalid option -- 'c'
I installed the Mysensor gateway on 17th October 2017 and my raspberry pi is working on Wheezy. In Domoticz, I see the Mysensor gateway has version 2.1.1.
MY gateway seems working fine, communicating properly with sensors (both ways). I'm trying to find log because I face an issue with a new sensor which works properly when powered with external FTDI 3.3V and only 1 way (sensor to gateway only) when powered on battery (I raised question in another post, where I was suggested to check log fil on gtw side..)
Any idea of what I should do (except "reinstall whole raspberry pi with latest OS..) ?
Thanks a lot,
@ricorico94 there seems to have been some major changes in the raspberry pi gateway, without vorresponding updates to the documentation.
I have not been able to locate the exact changes though. @marceloaqno might know.
Found the reference: https://github.com/mysensors/MySensors/pull/1061
ricorico94 last edited by
@mfalkvidd : thanks a lot ! I had searched for such version history and couldn't find it.
Indeed it seems introduction of the switches for log files was introduced in February, so I should probably update my install.
Precisely, talking about upgrade process: I read in previous posts that we should uninstall/unregister the install/service. WHat would be commands to do so ? Should it be:
sudo systemctl disable mysgw.service
and executed before anything else ? So upgrade process would be:
sudo systemctl disable mysgw.service make sudo make install sudo systemctl enable mysgw.service
(and maybe test the gateway before the "systemctl enable..")
Is there anyfile to remove manually ? or any other command to apply before or after ?
Would someone be willing to create a post that lists each step required to set up the simple encryption+signing option? I understand I have to add a password line to the arduino sketch. But how exactly one sets up the server side is still a bit of a mystery to me. It would rock if there was a similar simple command to give during the make process.
That is straight from the documentation. Which in the case of Linux ports is also what you get if you issue
pepson last edited by
I also need this info...
@ricorico94 to update your install run:
sudo make install sudo systemctl restart mysgw.service