💬 Building a Raspberry Pi Gateway
-
@mfalkvidd Maybe. I'm programmer, but not for Linux. My concern is the part of the service that creates the virtual device colliding between the instances.
I'll do a test in a virtual machine as soon as I have some time.
It should be something easy to test. -
@Sergio-Rius by "virtual device", do you mean the com port? If that's the caee, it can be specified with --my-serial-pty=
Ot let one gateway be serial and the other ethernet.
@mfalkvidd yes. Should work. I admit I've not taken a look at the code nor I don't know how to install the service two times.
I'm used to having problems with programs that use static resources allocation. But I don't know if that's the case. -
Hi guys couple of questions, apologies if they have been covered elsewhere.
I am running latest dev branches of domoticz and MYS on a pi2.
At random times it seems the NRF24L01+ LNA/PA goes down, or MYS goes down and domotics stops receiving signals from all of the nodes at the same time. I have the interrupt feature enabled.
I have set the option under domoticz/hardware/data timeout to restart if no data received in five minutes but I dont think this is an ideal solution, and have yet to find out if this domoticz feature actually works in my scenario.
Any idea what causes this? I found an old thread over on the domoticz/mysensors forum but no answers there. I am using a new sd card class 10.
What I want to do is try out the different MYS builds on domoticz ie MQTT and SERIAL as well as ethernet which I am currently running. However I'm not sure how to stop the current MYS service and completely clean up the current build to start from scratch... I have tried just re entering the ./configure commands then 'make' but this does not seem to work.
Many thanks,
Matt -
Hi guys couple of questions, apologies if they have been covered elsewhere.
I am running latest dev branches of domoticz and MYS on a pi2.
At random times it seems the NRF24L01+ LNA/PA goes down, or MYS goes down and domotics stops receiving signals from all of the nodes at the same time. I have the interrupt feature enabled.
I have set the option under domoticz/hardware/data timeout to restart if no data received in five minutes but I dont think this is an ideal solution, and have yet to find out if this domoticz feature actually works in my scenario.
Any idea what causes this? I found an old thread over on the domoticz/mysensors forum but no answers there. I am using a new sd card class 10.
What I want to do is try out the different MYS builds on domoticz ie MQTT and SERIAL as well as ethernet which I am currently running. However I'm not sure how to stop the current MYS service and completely clean up the current build to start from scratch... I have tried just re entering the ./configure commands then 'make' but this does not seem to work.
Many thanks,
Matt@Matt log files for the time where the problem occurred will be essential for troubleshooting.
make uninstall will stop the service and uninstall
make cleanconfig will remove previous ./configure settings
make clean will remove compiled code -
@Grubstake: Thanks. I have tried to follow "NRF24L01+ Radio" pin out connection. I have double / triple check my wiring is correct. But I still get the same fail message in mysgw debug mode:
[root@alarmpi bin]# ./mysgw -d mysgw: Starting gateway... mysgw: Protocol version - 2.1.1 mysgw: MCO:BGN:INIT GW,CP=RNNG---,VER=2.1.1 mysgw: TSM:INIT mysgw: TSF:WUR:MS=0 mysgw: !TSM:INIT:TSP FAIL mysgw: TSM:FAIL:CNT=1 mysgw: TSM:FAIL:PDT mysgw: TSM:FAIL:RE-INIT mysgw: TSM:INIT mysgw: !TSM:INIT:TSP FAIL mysgw: TSM:FAIL:CNT=2 mysgw: TSM:FAIL:PDT mysgw: TSM:FAIL:RE-INIT mysgw: TSM:INIT mysgw: !TSM:INIT:TSP FAIL mysgw: TSM:FAIL:CNT=3 mysgw: TSM:FAIL:PDT mysgw: Received SIGINTHere is my
/boot/config.txt:gpu_mem=64 initramfs initramfs-linux.img followkernel dtparam=spi=onand the spi dev:
# ls /dev/spidev0.* /dev/spidev0.0 /dev/spidev0.1I am using ArchLinuxARM:
# uname -a Linux alarmpi 4.9.13-3-ARCH #1 SMP Fri Mar 3 18:45:16 MST 2017 armv7l GNU/LinuxI only wiring 7 pins (1-7) on
NRF24l01+.Raspberry Pi 2 hardware information:
# cat /proc/cpuinfo processor : 0 model name : ARMv7 Processor rev 5 (v7l) BogoMIPS : 38.40 Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm CPU implementer : 0x41 CPU architecture: 7 CPU variant : 0x0 CPU part : 0xc07 CPU revision : 5 processor : 1 model name : ARMv7 Processor rev 5 (v7l) BogoMIPS : 38.40 Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm CPU implementer : 0x41 CPU architecture: 7 CPU variant : 0x0 CPU part : 0xc07 CPU revision : 5 processor : 2 model name : ARMv7 Processor rev 5 (v7l) BogoMIPS : 38.40 Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm CPU implementer : 0x41 CPU architecture: 7 CPU variant : 0x0 CPU part : 0xc07 CPU revision : 5 processor : 3 model name : ARMv7 Processor rev 5 (v7l) BogoMIPS : 38.40 Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm CPU implementer : 0x41 CPU architecture: 7 CPU variant : 0x0 CPU part : 0xc07 CPU revision : 5 Hardware : BCM2835 Revision : a21041 Serial : 00000000475d18a4 # cat /sys/firmware/devicetree/base/model Raspberry Pi 2 Model B Rev 1.1Output from MySensors
configure:# ./configure [SECTION] Detecting target machine. ./configure: line 111: warning: command substitution: ignored null byte in input [OK] machine detected: SoC=unknown, Type=unknown, CPU=armv7l. [SECTION] Checking GPIO Sysfs. [OK] /sys/class/gpio/export found [SECTION] Detecting SPI driver. [OK] SPI driver detected:SPIDEV. [SECTION] Detecting init system. [OK] init system detected: systemd. [SECTION] Saving configuration. [SECTION] Cleaning previous builds. [OK] Finished.I finally find out my raspberry pi board isn't detected properly in
configure. I change thefunction detect_machine:function detect_machine { ... case $hardware in ... BCM2835) soc="BCM2835" if [[ $machine == "Raspberry"* ]]; then local rev=($(detect_rpi_revision)) if [[ $rev == "a02082" || $rev == "a22082" ]]; then tp="RPi3" else tp="Rpi2" fi fi ;; ...make
mysgwagain, and I get this finally:# ./mysgw -d mysgw: Starting gateway... mysgw: Protocol version - 2.1.1 mysgw: MCO:BGN:INIT GW,CP=RNNG---,VER=2.1.1 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: Listening for connections on 0.0.0.0:5003 mysgw: MCO:BGN:STP mysgw: MCO:BGN:INIT OK,TSP=1 -
I'm just now testing the two instances installation. I was going to just alter the flag
--prefixbut now I see in options that there's also the install dir:Installation options: --prefix=<PREFIX> Installation prefix path. [/usr/local] --gateway-dir=<DIR> Gateway files installation directory. [PREFIX/bin]What do you think should be the preferred way for installing two instances, only changing
--gateway-dir? -
@Matt log files for the time where the problem occurred will be essential for troubleshooting.
make uninstall will stop the service and uninstall
make cleanconfig will remove previous ./configure settings
make clean will remove compiled code@mfalkvidd OK thanks for your reply.
Have set up the -d parameter in mysgw.servie and am waiting for it to fall over again.
If I catch it I will post syslog.
Thanks,
Matt -
Seems that I'll need some help for getting this properly done.
I can't launch two instances of the service.What I've done is following the guide instructions with the following configuration:
./configure \ --my-transport=nrf24 \ --my-rf24-irq-pin=18 \ --my-gateway=ethernet --my-port=5003 \ --prefix=/opt/mysgw-nrfThen manually executed it, and it run ok and get one test node connected and Domoticz saw it all.
Then I duplicated the MySensors folder and in there made the build with the following configuration:
./configure \ --my-transport=nrf24 \ --my-rf24-channel=82 \ --my-rf24-ce-pin=37 \ --my-rf24-cs-pin=36 \ --my-rf24-irq-pin=33 \ --my-gateway=ethernet --my-port=5004 \ --prefix=/opt/mysgw-rfmEven when it says rfm, i connected a second NRF with the following pinout (blue=first NRF, green=second):
*IRQ on pin 33 as config says, and power from 1.Then I tried to make and run and I get this output:
pi@domo_testing:~/MySGW_RFM $ sudo ./bin/mysgw -d mysgw: Starting gateway... mysgw: Protocol version - 2.2.0-beta __ __ ____ | \/ |_ _/ ___| ___ _ __ ___ ___ _ __ ___ | |\/| | | | \___ \ / _ \ `_ \/ __|/ _ \| `__/ __| | | | | |_| |___| | __/ | | \__ \ _ | | \__ \ |_| |_|\__, |____/ \___|_| |_|___/\___/|_| |___/ |___/ 2.2.0-beta mysgw: MCO:BGN:INIT CP=RNNG--Q- mysgw: TSF:LRT:OK mysgw: TSM:INIT mysgw: TSF:WUR:MS=0 mysgw: pinMode: invalid pin: 33 mysgw: pinMode: invalid pin: 37 mysgw: pinMode: invalid pin: 36 mysgw: digitalWrite: invalid pin: 37 mysgw: digitalWrite: invalid pin: 36 mysgw: You need root privilege to use SPI.Is that I have to connect MOSI and MISO to the same pins that the first NRF?
-
Seems that I'll need some help for getting this properly done.
I can't launch two instances of the service.What I've done is following the guide instructions with the following configuration:
./configure \ --my-transport=nrf24 \ --my-rf24-irq-pin=18 \ --my-gateway=ethernet --my-port=5003 \ --prefix=/opt/mysgw-nrfThen manually executed it, and it run ok and get one test node connected and Domoticz saw it all.
Then I duplicated the MySensors folder and in there made the build with the following configuration:
./configure \ --my-transport=nrf24 \ --my-rf24-channel=82 \ --my-rf24-ce-pin=37 \ --my-rf24-cs-pin=36 \ --my-rf24-irq-pin=33 \ --my-gateway=ethernet --my-port=5004 \ --prefix=/opt/mysgw-rfmEven when it says rfm, i connected a second NRF with the following pinout (blue=first NRF, green=second):
*IRQ on pin 33 as config says, and power from 1.Then I tried to make and run and I get this output:
pi@domo_testing:~/MySGW_RFM $ sudo ./bin/mysgw -d mysgw: Starting gateway... mysgw: Protocol version - 2.2.0-beta __ __ ____ | \/ |_ _/ ___| ___ _ __ ___ ___ _ __ ___ | |\/| | | | \___ \ / _ \ `_ \/ __|/ _ \| `__/ __| | | | | |_| |___| | __/ | | \__ \ _ | | \__ \ |_| |_|\__, |____/ \___|_| |_|___/\___/|_| |___/ |___/ 2.2.0-beta mysgw: MCO:BGN:INIT CP=RNNG--Q- mysgw: TSF:LRT:OK mysgw: TSM:INIT mysgw: TSF:WUR:MS=0 mysgw: pinMode: invalid pin: 33 mysgw: pinMode: invalid pin: 37 mysgw: pinMode: invalid pin: 36 mysgw: digitalWrite: invalid pin: 37 mysgw: digitalWrite: invalid pin: 36 mysgw: You need root privilege to use SPI.Is that I have to connect MOSI and MISO to the same pins that the first NRF?
-
@mfalkvidd That was the culprit. Thanks.
But now... seems that the radio that is using channel 76 also get connections from nodes on channel 83, and the second radio, the 83 one doesn't pick anything.Is there a way to confirm that gw and nodes are using one channel or other during the bootup?
-
@mfalkvidd That was the culprit. Thanks.
But now... seems that the radio that is using channel 76 also get connections from nodes on channel 83, and the second radio, the 83 one doesn't pick anything.Is there a way to confirm that gw and nodes are using one channel or other during the bootup?
-
@Sergio-Rius try increasing the distance between channels to at least 10 or more
-
@gohan Done. I've just burnt the node with channel 125 and it seems to have no effect. It registers on the 76 radio.
Does the
#define MY_RF24_CHANNEL 125has to be before or after the include of mysensors.h? I have it before.Well, I've changed the channel for the 1st radio to 83 and left the second at 125.
If I burn the testing node for ch125 it doesn't receives reply from the gw. If I then burn it on ch83, it registers and comunicates with the first radio.So I think the second radio does not work on the Raspberry Pi. The service communicates with the controller but does nothing for the network side.
Also on the second radio:mysgw: Client 0: 0;0;3;0;18;PING mysgw: Client 0: 0;0;3;0;18;PING mysgw: Client 0: 0;0;3;0;18;PING mysgw: !TSF:SAN:FAIL mysgw: TSM:FAIL:CNT=1 mysgw: TSM:FAIL:DIS mysgw: TSF:TDI:TSL mysgw: Client 0: 0;0;3;0;18;PING mysgw: TSM:FAIL:RE-INIT mysgw: TSM:INIT mysgw: TSM:INIT:TSP OK mysgw: TSM:INIT:GW MODE mysgw: TSM:READY:ID=0,PAR=0,DIS=0 mysgw: Client 0: 0;0;3;0;18;PING mysgw: Client 0: 0;0;3;0;18;PING -
Well, I've changed the channel for the 1st radio to 83 and left the second at 125.
If I burn the testing node for ch125 it doesn't receives reply from the gw. If I then burn it on ch83, it registers and comunicates with the first radio.So I think the second radio does not work on the Raspberry Pi. The service communicates with the controller but does nothing for the network side.
Also on the second radio:mysgw: Client 0: 0;0;3;0;18;PING mysgw: Client 0: 0;0;3;0;18;PING mysgw: Client 0: 0;0;3;0;18;PING mysgw: !TSF:SAN:FAIL mysgw: TSM:FAIL:CNT=1 mysgw: TSM:FAIL:DIS mysgw: TSF:TDI:TSL mysgw: Client 0: 0;0;3;0;18;PING mysgw: TSM:FAIL:RE-INIT mysgw: TSM:INIT mysgw: TSM:INIT:TSP OK mysgw: TSM:INIT:GW MODE mysgw: TSM:READY:ID=0,PAR=0,DIS=0 mysgw: Client 0: 0;0;3;0;18;PING mysgw: Client 0: 0;0;3;0;18;PING -
@Sergio-Rius if you shut down mysgw for the first radio and restart mysgw for the second radio, does the second radio start to work?
And do you get the same debug output? The SPI message looks bad. Maybe the two gateways are conflicting.@mfalkvidd Nope, the service seems to have stopped the SAN errors but still no communication:
pi@domo_testing:~/MySGW_RFM $ sudo ./bin/mysgw -d mysgw: Starting gateway... mysgw: Protocol version - 2.2.0-beta __ __ ____ | \/ |_ _/ ___| ___ _ __ ___ ___ _ __ ___ | |\/| | | | \___ \ / _ \ `_ \/ __|/ _ \| `__/ __| | | | | |_| |___| | __/ | | \__ \ _ | | \__ \ |_| |_|\__, |____/ \___|_| |_|___/\___/|_| |___/ |___/ 2.2.0-beta mysgw: MCO:BGN:INIT CP=RNNG--Q- 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: Listening for connections on 0.0.0.0:5004 mysgw: MCO:BGN:STP mysgw: MCO:BGN:INIT OK,TSP=1 mysgw: New connection from 127.0.0.1 mysgw: Client 0 connected mysgw: Client 0: 0;0;3;0;2; mysgw: Client 0: 0;0;3;0;2;Get Version mysgw: Client 0: 0;0;3;0;18;PING mysgw: Client 0: 0;0;3;0;18;PING mysgw: Client 0: 0;0;3;0;18;PING mysgw: Client 0: 0;0;3;0;18;PING mysgw: Client 0: 0;0;3;0;18;PING0 MCO:BGN:INIT NODE,CP=RNNNA--,VER=2.1.1 4 TSM:INIT 4 TSF:WUR:MS=0 12 TSM:INIT:TSP OK 14 TSF:SID:OK,ID=1 16 TSM:FPAR 51 TSF:MSG:SEND,1-1-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK: 2060 !TSM:FPAR:NO REPLY 2062 TSM:FPAR 2099 TSF:MSG:SEND,1-1-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK: 4106 !TSM:FPAR:NO REPLY 4108 TSM:FPAR 4145 TSF:MSG:SEND,1-1-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK: 6152 !TSM:FPAR:NO REPLY 6154 TSM:FPAR 6191 TSF:MSG:SEND,1-1-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK: 8198 !TSM:FPAR:FAIL 8200 TSM:FAIL:CNT=1 8202 TSM:FAIL:PDT 18206 TSM:FAIL:RE-INIT 18208 TSM:INIT 18214 TSM:INIT:TSP OK 18219 TSF:SID:OK,ID=1 18221 TSM:FPAR 18257 TSF:MSG:SEND,1-1-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK: 20267 !TSM:FPAR:NO REPLY 20269 TSM:FPAR 20305 TSF:MSG:SEND,1-1-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK: 22315 !TSM:FPAR:NO REPLY 22317 TSM:FPAR 22353 TSF:MSG:SEND,1-1-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK: 24363 !TSM:FPAR:NO REPLY 24365 TSM:FPAR 24401 TSF:MSG:SEND,1-1-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK: 26411 !TSM:FPAR:FAIL 26413 TSM:FAIL:CNT=2 26415 TSM:FAIL:PDT 36419 TSM:FAIL:RE-INIT 36421 TSM:INIT 36427 TSM:INIT:TSP OK 36431 TSF:SID:OK,ID=1 36433 TSM:FPAR 36470 TSF:MSG:SEND,1-1-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK: 38479 !TSM:FPAR:NO REPLY 38481 TSM:FPAR 38518 TSF:MSG:SEND,1-1-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK: 40527 !TSM:FPAR:NO REPLY 40529 TSM:FPAR 40566 TSF:MSG:SEND,1-1-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK: 42575 !TSM:FPAR:NO REPLY 42577 TSM:FPAR 42614 TSF:MSG:SEND,1-1-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK: 44623 !TSM:FPAR:FAIL 44625 TSM:FAIL:CNT=3You find the pinouts I send before are right to you?
-
MY_* defines need to be before #include MySensors.h so you're doing the right thing.
I don't know about the pins, have never used anything but the default wiring myself. But if the pins were wrong you should get TSM:INIT:TSP FAIL instead of TSM:INIT:TSP OK.If you reconfigure the first mysgw (the one with the default pins) to use channel 83, does communication with the node on channel 83 work?
-
MY_* defines need to be before #include MySensors.h so you're doing the right thing.
I don't know about the pins, have never used anything but the default wiring myself. But if the pins were wrong you should get TSM:INIT:TSP FAIL instead of TSM:INIT:TSP OK.If you reconfigure the first mysgw (the one with the default pins) to use channel 83, does communication with the node on channel 83 work?
@mfalkvidd yeah, look three posts before.
I'll try to get mosi and miso from the default pin out sharing with the first radio. Now I'm using the ones marked as 1, when the default ones are marked 0. -
@mfalkvidd yeah, look three posts before.
I'll try to get mosi and miso from the default pin out sharing with the first radio. Now I'm using the ones marked as 1, when the default ones are marked 0.@Sergio-Rius I see. Sorry. Then we know the channel parameter works. Good testing.
Strange problem. It looks from the threads I linked earlier that using the second SPI does indeed work (if the pin definition fix is applied). When the first mysgw is stopped, your second mysgw should behave just as it did for Velo17 and wergeld. Can you think of any difference in your setup? -
@Sergio-Rius I see. Sorry. Then we know the channel parameter works. Good testing.
Strange problem. It looks from the threads I linked earlier that using the second SPI does indeed work (if the pin definition fix is applied). When the first mysgw is stopped, your second mysgw should behave just as it did for Velo17 and wergeld. Can you think of any difference in your setup?@mfalkvidd I have the impression that if I stop the first service, the second picks the first radio.
I disconnected the power from the first radio and left the second all connected and I only got TSM errors and fails. As soon as I attached power to the first NRF it worked.
Perhaps the other users only used the configurable pins (CS/CE/IRQ) on the extended bank...
