Home Automation Domotica Forum Europe, Bwired Forum

casio wrote:Not sure but just before things go err there is an error 3 reported on which the gateway reduces the power to medium followed by a second error 3.

The Celcia 20 doesn't support smart power, so the medium power request must have been detected erroneously. As a result of this misunderstanding the gateway starts sending different bit levels. It's not surprising that the thermostat then doesn't understand the messages anymore and reports a communication error.

I will have to find a way to either prevent or recover from this situation. The methods that come to mind are:

1. Only accept smart power requests if the thermostat has indicated support for it.
2. Return to low power mode if the thermostat repeats the same message some number of times.

casio wrote:Finally, I noticed that with the Celcia 20 if you use TT=xx the thermostat programmed timer is not picking up. Is this related to the fact that the TT command is actually a TR command under the hood after the gateway detected that the thermostat is a Remeha Celcia?

I think the answer is yes, but the question is not entirely clear to me. After a while the gateway figures out that your thermostat is a Celcia 20 (you can check with PR=R). It will then use the Celcia specific method for manipulating the setpoint. The Celcia doesn't allow any distinction to be made between TT and TC.

Not completely familiar with the smart power concept, but is it comparable with modulation depth to end up with more average available power? Option 1 sound like a save solution (disable the smart power options). Except all other thermostats than Remeha will automatically have the smart power enabled. While maybe not supported/required. Maybe it is good to add an additional option, e.g. SM (smart power ) = 0 or 1? The option could be preset if, e.g. the iSense thermostat is recognized.

I indeed checked with PR=R and it correctly reported C so we are on the same page. That is a pity (limitation of the thermostat). However, this is solvable by creating a simple of cronjob. In case we leave the override active, it checks for that (if [PR=O] == Txx.x), and puts the setpoint to 17degC as the thermostat program would do... Any way, thanks for confirming.

Hi all,

As follow up from my previous post, it seems the opentherm gateway is sensitive for disturbances on the serial connection:

(1) if I leave the serial connection open (no connection) for longer time (hours) the otgw will start outputting repeatedly the following 4 bytes: 0x4F 0x70 0xFF 0x04. The thermostat reports "no communication". Touching the serial connection with a finger will get the otgw going again.
(2) The situation described above can be reproduced easily by connecting the serial port to the serial port (uart 2) of an Arduino Mega 2560. When resetting the Arduino the otgw will go in the mode as described above.
(3) When resetting the otgw after the resetting the Arduino, the otgw will operate normally. And stable, it is already running at my house for more than a week.

I created a work around by hooking up the reset of the otgw to a digital pin of the Arduino. And letting the Arduino reset the otgw after startup.

It would be nice to make in the future the otgw more robust for disturbances on the serial connection. But no high priority (for me).

Cheers!

My setup is:
Boiler: Intergas Kombi Compact HR 36/30
Thermostat: Honeywell Chronotherm vision modulation
FW version 4.0a11
TTL to USB converter cable with Prolific chip.

Overnight I let the otgw work "stand alone" (no computer connected to the USB cable). When I woke up this morning the thermostat was reporting "no communication" and the heating was off. To see what was going on I connected a laptop to the USB cable with realterm. When I made the connection the heating started again and thermostat started operating normally again (I don't remember if it happened when I connected the USB cable or when I openend Realterm). Realterm showed that the otgw was outputting repeatedly the following 4 bytes: 0x4F 0x70 0xFF 0x04 (no ascii but raw bytes). After disconnecting/connecting the USB cable, Realterm was showing opentherm messages in the usual ascii format again. And everything seems to be operating normal again. I kept it running and it's running now fine again for an hour or so.

Not sure if this is hw/sw or related to the open serial connection. But I'll keep it running and see if I can reproduce. Suggestions are welcome.

Cheers!

My serial connection is open 24x7 for months without any problem.

Some background information: When the gateway sees a so-called BREAK condition on the serial line, it goes into self-programming mode. When entering this mode, the gateway sends a 0x04 byte and waits up to one second for a 0x0F response. If that doesn't happen, it restarts normal operation. The first thing it transmits as serial data is "OpenTherm Gateway 4.0a11".

So, what likely is happening is that the TTL to USB converter generates a BREAK condition. The gateway sends 0x04 and waits for a response which it doesn't get. It then starts sending the banner string. After the first two characters ('O'=0x4F 'p'=0x70) and the start bit of the third character the converter generates another BREAK condition, which puts the gateway into self-programming mode again. The serial transmit line gets reset and goes high, seemingly producing a 0xFF byte. Then the gateway sends 0x04 and waits for a response, etc.

I'm not exactly sure why the converter sends a BREAK, which is essentially a prolonged low state of the serial line. Maybe, when it is not powered via USB, it also pulls the TTL output low. Or it may be trying to buffer the received serial data and when the buffer is full it generates a BREAK. Is there any way to power the device from the TTL side and program it to discard the serial data if it can not deliver it through USB?

That is a plausible explanation. I'll try to borrow a logic analyzer from work (when one is not used) and to see what is exactly going on. With the otgw/arduino setup I can easily reproduce the situation. I'll keep you posted.

Hi Guru

i have the same setup as you have, same CV, same thermostat and same FW.
i am not using arduino but a domotics system. my connection to the domotica is using the serial to network converter TPlink.

It is running for weeks with no problems.

Hi Schelte,

I'm running firmware version 4.0a11 in combination with a Celcia20 Thermostat and I'm having problems returning back from temporary setpoint override. Setting a temporary setpoint via TT and TC command is fine, but TT=0 or TC=0 doesn't have the proper result. The room setpoint stays on the temperature temporary set by the TT/TC command. Only resetting on the Calcia20 thermostat brings the control back to the Celsia20 program. The Gateway does recognize the Celcia20 (PR=R gives C).

Do you guys update the firmware over a serial->LAN interface? Or is this to tricky and for updates you connect it directly to the serial interface of the computer?

I only have a LAN interface on the OTG (USR-TCP232-T), so I always use that for a firmware update (no issues).

I'm using an external Serial to Ethernet converter (USR-TCP232-2), I'm doing the firmware upgrade via that converter. I have to give a manual reset to get the upload starting, now possible via the Serial Reset command, before via reset pins on the gateway.

I have noticed that when the outside temperature is 0°C or below, I got the next result:
On the I-sense I have the correct outside temperature, and the outside senser is ok!
Does anyone else got the same?

Looks you are using the Vera plugin and that doesn't handle negative numbers well yet. I'll correct the code, thanks.

Looks you are using the Vera plugin and that doesn't handle negative numbers well yet. I'll correct the code, thanks.

Ok,
I have installed the latest version.
I will let you know tonight if its working correct. Have to wait untill its freezing.

Hi Schelte,

I've now installed version 4.0a11 and all looks good so far.

Is there a command that prints out all the cusom settings, such as UI, AA, etc. so when the next version of software comes out its easy to note down any changes (those stored in EEPROM) I've made that would be lost during an upgrade?

Many Thanks

Richard