I have maybe a newbie question.
I have recently purchased a assembled OTGW on nodoshop.nl.
I have the following configuration
Boiler: Intergas Kombi Kompakt HR 36/30
Thermostat: Honeywell Chronotherm Vision (TH8110M1003)
OTWG: nodoshop.nl type, with ESP 8266 (Node MCU V3), firmware 4.2.5 (determined by sending GW=R)
I have established the connection with otmonitor trough the ESP8266 and communication looks fine (no error in otmonitor or misformed characters)
However i noticed 3 points of concern:
1 Serial command has to be issued serveral times before accepted
When a serial command is invoked through otmonitor in the options Miscellaneous, i not alway get a response.
According the documentation after sending a command, for example <TT=17.0>, the gateway should respond with <TT: 17.0> if the command is accepted.
If the gateway fails to parse the command it should response with (NG, SG BV OR NS,NF or OE).
I mostly have to send the command 2-4 times before i get the expected response <TT:17.0>. It look like the earlier sent command are ignored or not received, because i don't get any other response.
Is this normal behaviour?
2 MQTT operation of otmonitor
Is the MQTT client checking the response and if no response is received is the command automaticly restransmitted?
3 Duration of setpoint change in Thermostat
If a <TT=17> command is accepted it takes 2-3 minutes before this is actally commited to the thermostat (Room temperature setpoint). The override room setpoint is changing within the next reveice of the telegramm
Br. Jodur
OTGW normal Behaviour
Moderator: hvxl
Re: OTGW normal Behaviour
No, this is not normal behaviour. Most likely this is caused by the ESPEasy firmware on the NodeMCU. I understand the Nodoshop guys are already working with you towards a solution.jodur wrote:1 Serial command has to be issued serveral times before accepted
When a serial command is invoked through otmonitor in the options Miscellaneous, i not alway get a response.
According the documentation after sending a command, for example <TT=17.0>, the gateway should respond with <TT: 17.0> if the command is accepted.
If the gateway fails to parse the command it should response with (NG, SG BV OR NS,NF or OE).
I mostly have to send the command 2-4 times before i get the expected response <TT:17.0>. It look like the earlier sent command are ignored or not received, because i don't get any other response.
Is this normal behaviour?
No. Considering the answer on #1, a missing response can not usually be resolved by simply trying again. So there was no reason to implement a retry strategy.jodur wrote:2 MQTT operation of otmonitor
Is the MQTT client checking the response and if no response is received is the command automaticly restransmitted?
It is normal that it takes some time for a TT command to take effect. The gateway has to wait for the thermostat to inquire about an override setpoint. A thermostat may query that parameter only once per 1 or 2 minutes. The thermostat may also need to get the same response more than once to avoid an accidental setpoint change. After the setpoint change, it takes some time before the thermostat reports the Room temperature setpoint parameter. The thermostat will usually already use and display the new setpoint before that last report.jodur wrote:3 Duration of setpoint change in Thermostat
If a <TT=17> command is accepted it takes 2-3 minutes before this is actally commited to the thermostat (Room temperature setpoint). The override room setpoint is changing within the next reveice of the telegramm
I don't understand your last sentence.
Schelte
Re: OTGW normal Behaviour
Thnx for the reply.
The fault was on the hardware side of the OTGW. The Nodoshop solved this very nice!
I have it no stable up and running with my homeassistant!
Thnx for this awesome project!
The fault was on the hardware side of the OTGW. The Nodoshop solved this very nice!
I have it no stable up and running with my homeassistant!
Thnx for this awesome project!
Re: OTGW normal Behaviour
Hi jodur,
Can you please let us know what was wrong with the hardware in your 1. point of concern?
I seem to have a similar issue: Sometimes the <TT=...> command is not interpreted by the gateway. Most of the times it works, but not always.
Can you please let us know what was wrong with the hardware in your 1. point of concern?
I seem to have a similar issue: Sometimes the <TT=...> command is not interpreted by the gateway. Most of the times it works, but not always.
Re: OTGW normal Behaviour
The problem in my case was resistor. But this wasn't the main problem. The case of missing a command was an issue with the espeasy firmware.
The problem doesn't apperar when you use the esplink firmware from Jeelabs. Somehow there is a bufferproblem with the espeasy firmware.
If you have purchased a recently otgw from the nodoshop there is also a hardware watchdog timer connected, so is you want to use the Jeelabs firmware, you only connect the powersupply (+,-) and the RX and TX of the Node V3.
The Jeelab firmware can't handle the watchdog so you have to byspass it.
The problem doesn't apperar when you use the esplink firmware from Jeelabs. Somehow there is a bufferproblem with the espeasy firmware.
If you have purchased a recently otgw from the nodoshop there is also a hardware watchdog timer connected, so is you want to use the Jeelabs firmware, you only connect the powersupply (+,-) and the RX and TX of the Node V3.
The Jeelab firmware can't handle the watchdog so you have to byspass it.
Re: OTGW normal Behaviour
@ jodur, Thanks for your quick reply!
I build the OTGW myself, and I already use the esp-link from Jeelabs, but I think the problem is in the tcp-out-node of Node-RED. Might be a connection issue. When this is confirmed, or when I have the solution, I will post it here.
*update*: The issue is not in my OTGW, but in Node-RED. I will try to solve it there.
I build the OTGW myself, and I already use the esp-link from Jeelabs, but I think the problem is in the tcp-out-node of Node-RED. Might be a connection issue. When this is confirmed, or when I have the solution, I will post it here.
*update*: The issue is not in my OTGW, but in Node-RED. I will try to solve it there.
Re: OTGW normal Behaviour
@jodur, I have also bought a recent otgw from Nodo shop. Also faced some issues to get it working. Also TT= needs to be issued several times before a TT: appears, same buffer problem. Regarding the Jeelab firmware, which version are you using and how did you manage to get only power and RX and TX connected? I am using the headers on the PCB so see no easy way to isolate the other pins.
Little off topic, one was that the PIC socket wasn't tight enough, only when I pushed on the PIC the board would run. Solved this by very, very, slightly bending the pins of the PIC forcing proper continuity.
Little off topic, one was that the PIC socket wasn't tight enough, only when I pushed on the PIC the board would run. Solved this by very, very, slightly bending the pins of the PIC forcing proper continuity.