Opentherm Gateway 4.0 alpha/beta testers wanted

[hvxl]

Sorry to hear that. Did you get a chance to look at what was going on before you reset everything?

The only real change since the previous version is the outside temperature sensor support. Did you also run 4.0a4 for a while before switching to 4.0a5?

I did find that I may not be doing the outside temperature sensor actions at the intended moment. The plan was to interact with the sensor in the lull between sending the response of one message back to the thermostat and receiving the next message from the thermostat. According to the specs there should be an interval of at least 100 ms where there is no activity on the opentherm line.

However, I'm looking at the wrong bit to determine that moment. So instead of calling the subroutine after sending a message to the thermostat, it may happen after sending a message to the boiler. According to the specs there should still be a gap of 20 ms before the boiler sends back the reply, which would be more than enough for the gateway to figure out there is no sensor connected. That takes a maximum of 2.2 ms and I have some detection in place to abort the temperature conversion if an opentherm message starts coming in.

But even if the temperature sensor work interferes with message reception on occasion, the next message should be fine again. I don't expect the iSense to report a problem as soon as it misses one response.

What I'm trying to say is that I can't begin to speculate on a reason for this event without more information (in the form of logs). I'm running 4.0a5 myself and haven't noticed any problems like this or even an increase in the number of errors reported by the gateway.

[bonza]

Installed 4.0a5 and testing. Tnx for the new features.

[sj3fk3]

I would not start to worry about this when it's just a one-off. I'm going to run the otmonitor with logging on for a while now (and also run some test that are long over due). I'll leave the log running the whole night and see if it shows anything interesting.

[sj3fk3]

Ok, setting QT (with an iSense) again after the first one was successful, results in failure. It's fails to set the new temperature, instead the system falls back to the original program. Changing the roomsetpoint by hand (at the iSense) also results in failure (the original program takes over).

Overriding with QT once, does seem to work however. Still need to see what happens with it when program changes.

[blb]

Hi Schelte,

I have installed the latest fw version (gateway-4.0a5.hex). Update itself went flawless via my IP to Serial converter with the OT monitor connected to the IP address and a power down/up of the gateway to get it in self-programming mode. After that my combination with Celica 20 works as before. After start-up no strange date any more after PS=1, thanks Schelte!

[wbvreeuwijk]

Hi Schelte,

I installed the latest FW 4.0a5 just now and found that the SW command replies with NG. Is this caused by:
"With boilers that do not support the remote boiler parameter DataID's (6, 48, 49, 56, and 57), the gateway will simulate at least read support. In this case the values provided via the SH and SW serial commands are returned to the thermostat."

I've gone back to version 4.0a3 and it seems to be broken there also. It's working in 3.4.

Regards,
Bas.

[Rutger]

I replaced my iSense with a used Celcia 20 thermostat because of the many override issues. With firmware 4.0a5 everything works fine.

[hvxl]

Bas,

The SW command checks the bits returned in a response on DataID 6. If the boiler doesn't allow read/write access to the DHW setpoint (bit 0 of the low byte is cleared), the SW command replies with NG. That hasn't changed between 3.4 and 4.0a5. How does your boiler respond to a request for DataID 6? What do you get if you dump the variable that stores the DataID 6 value (DP=51 for firmware 3.4 or DP=53 for firmware 4.0a5)?

Actually, the SW command should no longer be checking the bit to allow a hot water setpoint to be returned to the thermostat if the boiler doesn't support the DataID, so I will fix that in the next version.

[hvxl]

I replaced my iSense with a used Celcia 20 thermostat because of the many override issues.

Any chance I can borrow that iSense for a while if you are not using it anymore? Then I can see if I can find ways to improve how the gateway works with an iSense.

[Rutger]

Hi Schelte, that's was my idea also, but I'll wait with sending my iSense to you untill monday, so I can trust on my Celcia 20 for that long period.
You can PM your address in the meantime.

[ReneZuidam]

Dear Schelte,

Nice update with the external 1 wire sensor would like to use it
for the Return Temp of CV instead of Outside Temp could this be an configurable option,
based on your feedback concerning stop of communicaiton with Thermostat in the post before thi sone i will give
this last Firmware an go..currently running the 4.0a4 without any hickups . (besides my already pre existing timing issue's error 2/3 with Chronotherm Wireless)

greetings Rene..

[flue]

Schelte,

This firmware is working like a charm for almost 2 weeks now.
I'm using, as you know, a cecia 20 with a quinta 80c. Also the problems we have discussed before by email are completely gone with this firmware!

Thanks!

[macaidwin]

I am brand new here, I just bought a Remeha Tzerra and a Remeha iSense (not knowing the iSense is buggy).
And I have connected the opentherm-gateway.
I tested the default gateway.hex, the beta gateway-4.0a5.hex and the isense147.hex
The isense147.hex works most predictable with the buggy iSense.
You can set a remote setpoint, it will set de room setpoint. The second time you set a remote setpoint it will go back to 20.0. After that, you can set a room setpoint successfull again.
With the 4.0a5.hex the setpoint goes to 20.00 at unpredictable moments, also during the night.

Maybe I don't tell anything new, but I like to share it.

[macaidwin]

I am now back on isense147.hex
And what I notice is that when I send a remote command the first time, for example TT=15, the command is send several times as
Read-Data Remote override room setpoint: 0.00
Read-Ack Remote override room setpoint: 0.00
Read-Ack Remote override room setpoint: 15.00
The next time the room setpoint is reported, it is actually 15. Thats okay, it works and stays there for hours.

But the next time I send for example TT=19, log shows:
Read-Data Remote override room setpoint: 0.00
Read-Ack Remote override room setpoint: 0.00
Read-Ack Remote override room setpoint: 19.00

But the room setpoint does't change OR it changes, but the gateway keeps sending the same commands for a while (I think). But during a longer time of period I see the remote override 0.00 in the log. Does the gateway send this? Or the boilor? Or iSense?
Read-Data Remote override room setpoint: 0.00
Read-Ack Remote override room setpoint: 0.00
Read-Ack Remote override room setpoint: 0.00

The isense responds with raising the room setpoint in steps to 20.00. Steps like 19.12 , 19.34 , 19.47 , 19,54 etc.

Then the room setpoint stays at 20.00, but I still see:
Read-Data Remote override room setpoint: 0.00
Read-Ack Remote override room setpoint: 0.00
Read-Ack Remote override room setpoint: 0.00

After that, I can set another TT normally.

So, why I see it goes right the first time and goes wrong the second time?
Why it stops sending the manual set value and goes back to 0.00?
Maybe the best way to remote change the iSense is to keep sending the wanted value, even if the room setpoint is already changed to that value.

Maybe this helps a bit....

[hvxl]

Can someone with a Remeha iSense and a Smart Power capable boiler describe to me what happens when the iSense is first connected to the boiler (without the gateway in between and no batteries installed)?

I have obtained a few more shreds of information about the Smart Power feature and am trying to make the iSense backlight work with the gateway. Unfortunately I have not been able to get my hands on the actual specification, so I have to fill in some blanks by trying, guessing and observing.

I have had some success with making the iSense backlight work during normal operation. But when first connecting the thermostat, the backlight comes on quite dim. It then briefly brightens and dims about once a second, probably coinciding with receiving opentherm messages.

So, I would like to know if this is the normal behaviour, or should the iSense normally show a steady bright backlight after it is connected? If so, I have to adjust my understanding of how Smart Power is supposed work.