It became a bit of a long story, let me know if it (does not) makes sense.
And thanks in advance for reading.
---
I was planning to build my own OTGW for a long time allready.
Last week I ordered one at nodo-shop with a node-mcu.
After putting it together, and testing the voltages I got it up and running with nodemcu (espeasy r147) and otmonitor on my laptop quite fast.
One thing on the voltages, got 1.21 volt on pin 1 but the pin which was supposed to have 4.5 volt had 5, rest was ok.
Commands got received and it was spitting out lots of 0's.
I then connected it between the thermostat and boiler (near the boiler) and voilla otmonitor got data on temperaturs, burner status etc.
So far so good.
Then I put otmonitor in relay mode and connected domoticz, thats where it got weird.
Domoticz sends out 4 commands directly after eachother quite fast, first one sets the clock, last one does PS=1.
I saw them in the otmonitor messages log.
However the response in otmonitor showed either:
-SE
-gateway reset
-OE
-first 1 or 2 commands answered, rest one of the above.
Where after gateway reset the PR=Q returned L (Break on serial interface).
So I flashed espeasy 2.x (and wrote a mail to nodo-shop because the voltage regulator gets really, really hot.
They replied that they will send a new board (with buck converter) somewhere in the future.
With espeasy 2.x it looked better. It only occasionally did a reset but only once every 1- 10 minutes the PS=1 command got answered,
in other cases nothing came in reply of the PS=1 or only commands 1-3 got answered (visible on the otmonitor). 5 times the gateway resetted itself in 24hours.
(Mind that all 4 commands are relayed by otmonitor).
So I read some more and thought it was an espeasy issue, so I flashed esp-link (latest) and things got weird again.
First I found out the nodo board has an attiny watchdog connected to the i2c of the nodemcu, this only works with espeasy so I had to disconnect the i2c pins
otherwise the nodemcu got restarted every so often. After that i set it up with otmonitor and domoticz and....Same as first attempt. SE, OE or restart.
By then it could be reproduced without domoticz, just from otmonitor sending 4 times PS=1 quickly would trigger a gateway reset.
Send another mail to nodo-shop, they said it must be the software, go ask online...
The OTGW at this time was removed from the production and put back in testlab because the wife began complaining the thermostat defaulted to the program instead of the 21 degrees she prefers
Not giving up easily I tried again, with connecting the otgw (pic pins 8 and 11) to the raspberrypi GPIO (with logic level converter).
Running otmonitor on the pi. Little better but 2 times out of 3, same behaviour.
Today I unearthed an ftdi cable from the attic, and tada... works like a charm, clicked my finger till it hurts sending commands, always reply, no errors.
So it's going back in production tonight using a rpi with lan as bridge, let's see if it keeps on working.
Now I'm wondering who amoung you, Using serial interface (RX to TX and TX to RX using, arduino, rpi, nodemcu, esp-xyz), can send 4 - 10 subsequent commands
rapidly after eachother without causing a gateway reset or SE, OE?
Who can explain this behaviour?
(Maybe) I will try recompiling domoticz with a sleep of half a second between commands, will most likely fix it, but I am still wondering, do I have
a bad board, bad pic or....
PS: Not one for sucking up but I really like the work put into this gateway, both hardware and software, learning a lot.
Wilco
(Nodo Shop) OTGW trouble with receiving commands
Moderator: hvxl
Re: (Nodo Shop) OTGW trouble with receiving commands
Just a small remark: If PR=Q returns L, it means that the last reset was because the gateway detected that the thermostat kept sending the same message 64 times in a row (iow, it was stuck in a Loop).
Schelte
Re: (Nodo Shop) OTGW trouble with receiving commands
Thanks for pointing that out. It did (also) occur without thermostat or boiler connected.
I hooked it back up to rpi gpio with llc and rechecked if it was (L)oop or (S) break on serial interface.
I hooked it back up to rpi gpio with llc and rechecked if it was (L)oop or (S) break on serial interface.
Code: Select all
21:47:56.143000 Command (via websocket): PS=1
21:47:56.157274 PS: 1
21:47:56.289200 00000000/00000000,0.00,00000000/00000000,0.00,0/0,0.00,0.00,0.00,0.00,0.00,0.00,0.00,0.00,0/0,0/0,0.00,0.00,0,0,0,0,0,0,0,0
21:47:56.347932 Command (via websocket): PS=1
21:47:56.362125 PS: 1
21:47:56.497674 00000000/00000000,0.00,00000000/00000000,0.00,0/0,0.00,0.00,0.00,0.00,0.00,0.00,0.00,0.00,0/0,0/0,0.00,0.00,0,0,0,0,0,0,0,0
21:47:56.493730 Command (via websocket): PS=1
21:47:56.510121 PS: 1
21:47:56.639979 00000000/00000000,0.00,00000000/00000000,0.00,0/0,0.00,0.00,0.00,0.00,0.00,0.00,0.00,0.00,0/0,0/0,0.00,0.00,0,0,0,0,0,0,0,0
21:47:56.651387 Command (via websocket): PS=1
21:47:56.665666 PS: 1
21:47:56.748559 Command (via websocket): PS=1
21:47:56.809023 00000000/00000000,0.00,00000000/00000000,0.00,0/0,0.00,0.00,0.00,0.00,0.00,0.00,0.00,0.OpenTherm Gateway 4.2.5
21:47:56.827683 Thermostat disconnected
21:47:56.868386 Command (via websocket): PS=1
21:47:56.882641 PS: 1
21:47:57.014587 00000000/00000000,0.00,00000000/00000000,0.00,0/0,0.00,0.00,0.00,0.00,0.00,0.00,0.00,0.00,0/0,0/0,0.00,0.00,0,0,0,0,0,0,0,0
21:48:04.444054 Command (via websocket): PR=Q
21:48:04.462382 PR: Q=S
Re: (Nodo Shop) OTGW trouble with receiving commands
PR: Q=S means that the gateway was reset by an external source. In this case the RPi apparently kept the serial line at a low logical level for an extended amount of time. That is not a issue with the OTGW.
Schelte