💬 Building a Raspberry Pi Gateway

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

mfalkvidd

@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

enlo

@ccy that correction to the detect_machine function was necessary on my Rpi 3 too (I took the latest version from master). I got it working with that addition.
Soooo I guess that would be worth adding to the code / opening an issue on github, wouldn't it?

Sergio Rius

I'm just now testing the two instances installation. I was going to just alter the flag --prefix but 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

@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

Sergio Rius

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-nrf

Then 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-rfm

Even 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

@Sergio-Rius see https://forum.mysensors.org/post/72145 and https://github.com/mysensors/MySensors/issues/895

Sergio Rius

@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?

gohan

@Sergio-Rius try increasing the distance between channels to at least 10 or more

Sergio Rius

@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 125 has to be before or after the include of mysensors.h? I have it before.

Sergio Rius

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

mfalkvidd

@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.

Sergio Rius

@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;PING

0 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=3

You find the pinouts I send before are right to you?

mfalkvidd

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?

Sergio Rius

@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

@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

@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...

Sergio Rius

That's it. It doesn't use MOSI, MISO and SCLK from the SPI1. I removed the NRF1 and only connected those tree pins of NRF2 into SPI0 and service2 works with NRF2 at channel 125.

I've tried to share those pins (MOSI, MISO, SCLK) between both radios but as soon as I connect NRF1, 2 stops communicating. Same effect than connecting NRF2 to SPI1.

What a pity... #@%&!!! :grinning:

Edit: I finally tried a more "standard" configuration. Using only the first SPI bank and also doesn't work.

Roman

Hi!
I have a problem with the pseudo port. Node-serialport (v4.0.7) on the command serialport.list produces the result of the undefined.

Rpi3 and DietPi, nodejs 4.8.4

Matt

@mfalkvidd OK have attached the logfiles below.
No clues that I can see. At 1502 the NRF goes quiet. I have tried a different pi2, different NRF (PA/LNA) and am currently running the NRF off of 5V from the PI through one of those $1.00 regulator adapter things with built in caps and such. Have also tried different PSUs including a 2A one.
Only thing I can think left to try is reducing the power output in case the high output of the radio module is inducing transients in the cables...
Am kinda stumped here. I have an arduino NRF gateway that I will try via USB if low power does not work. I have tried setting up MYSGW as LAN and USB via ./configure but the same thing happens each time.
One thought just came to me, I AM using the pin15 IRQ option on the NRF now that is still experimental?
So next time will try without IRQ and low power...

Any help/suggestions greatly appreciated.
FYI I have had domoticz running on a lubuntu netbook with USB arduino NRF gateway that has been rock solid. Am trying the get a workable PI solution though, for myself and my father in law but not workable as yet sadly...

At 15:02:34 you can see the last incoming node message after that the only MYSGW activity is the PING thing... which seems to happen every 10S or so. This goes on for an hour after that with no more incomings. I have ~12 sensors around the place including a power meter one which reports every minute.

15:02:29 raspberrypi dhcpcd[734]: wlan0: Router Advertisement from fe80::260:64ff:fed7:f613
Aug  5 15:02:33 raspberrypi mysgw: TSF:MSG:READ,23-23-0,s=1,c=1,t=0,pt=7,l=5,sg=0:18.0
Aug  5 15:02:33 raspberrypi mysgw: TSF:MSG:READ,23-23-0,s=0,c=1,t=1,pt=7,l=5,sg=0:21.0
Aug  5 15:02:34 raspberrypi mysgw: TSF:MSG:READ,23-23-0,s=255,c=3,t=0,pt=1,l=1,sg=0:68
Aug  5 15:02:34 raspberrypi dhcpcd[734]: wlan0: Router Advertisement from fe80::260:64ff:fed7:f613
Aug  5 15:02:36 raspberrypi mysgw: Client 0: 0;0;3;0;18;PING
Aug  5 15:02:37 raspberrypi mysgw: TSF:MSG:READ,41-7-0,s=0,c=1,t=0,pt=7,l=5,sg=0:11.6
Aug  5 15:02:41 raspberrypi dhcpcd[734]: wlan0: Router Advertisement from fe80::260:64ff:fed7:f613
Aug  5 15:02:46 raspberrypi mysgw: Client 0: 0;0;3;0;18;PING
Aug  5 15:02:50 raspberrypi dhcpcd[734]: wlan0: Router Advertisement from fe80::260:64ff:fed7:f613
Aug  5 15:02:56 raspberrypi mysgw: Client 0: 0;0;3;0;18;PING
Aug  5 15:02:57 raspberrypi dhcpcd[734]: wlan0: Router Advertisement from fe80::260:64ff:fed7:f613
Aug  5 15:03:06 raspberrypi dhcpcd[734]: wlan0: Router Advertisement from fe80::260:64ff:fed7:f613
Aug  5 15:03:06 raspberrypi mysgw: Client 0: 0;0;3;0;18;PING
Aug  5 15:03:13 raspberrypi dhcpcd[734]: wlan0: Router Advertisement from fe80::260:64ff:fed7:f613
Aug  5 15:03:16 raspberrypi mysgw: Client 0: 0;0;3;0;18;PING

Also FWIW to log from domoticz below. Ignore FANFLAG thats just a blockly flag I use...

2017-08-05 15:01:18.936 (GW) General/Voltage (FanIntakeV)
2017-08-05 15:02:04.935 (GW) General/kWh (Meter)
2017-08-05 15:02:33.940 (GW) Temp + Humidity (Mitch2)
2017-08-05 15:02:33.945 (GW) Temp + Humidity (Mitch2)
2017-08-05 15:02:37.941 (GW) Temp (MBR Fan)
2017-08-05 15:50:02.678 Set UserVariable FanFlag = 1
2017-08-05 15:51:02.693 Set UserVariable FanFlag = 1
2017-08-05 15:52:02.703 Set UserVariable FanFlag = 1
2017-08-05 15:53:02.710 Set UserVariable FanFlag = 1
2017-08-05 15:54:00.037 Set UserVariable FanFlag = 1

Thanks,
Matt

💬 Building a Raspberry Pi Gateway

16

11.7k

11.2k

113.0k