[OTGW] Remeha Quinta 30C

[Chriskras]

As some already know I want to hang between my boiler thermostat and a Gateway so I can see the boiler thermostat to the communication.

Just a sketch, so I have a Remeha Quinta 30C.
It is connected as follows:


Now I have this box connected between the boiler and the thermostat.
The thermostat can I read but the boiler does not.

I get the following data from the boiler:

This log is created with the diagnosis firmware Opentherm Gateway

The "Round Clock Deluxe" indicates the diagnostic firmware the following:

It shows that it actually has a communication with the Open Therm Gateway.

What I have tried is:

• In place of the modulating clamps are used on the boiler, tried the on / off clamps.
  This had the effect that I would be successful boiler connect to the Open Therm Gateway and remove immediately went down the boiler.
• Tried other thermostat, same result (Honeywell Modulation (1997-2003))
• Boiler reset with the reset button on the boiler
• Removes resistance between terminal 3 and 11, no effect
• Removes yellow wire, no effect
• Opentherm Gateway taken off several times from the current
• The latest firmware inside shot, gateway 4.0b1 unfortunately does not help that
• The latest monitor tool used Monitor 4.0b3
• Diagnosis (version 1.1) firmware tried above what the outcome
• Tried with the stable version of the firmware (version 3.4)
• Also tried the stable version (3.3) of the monitor

The boiler is not in the matrix at the site.
http://otgw.tclcode.com/matrix.cgi
But my idea is Opentherm simply Opentherm and it should just work.

Topic in dutch: http://gathering.tweakers.net/forum/lis ... es/1577141
I'm from the dutch and that is my native language

[Chriskras]

I checked the Gateway with this list:
http://otgw.tclcode.com/debugging.html and then Opentherm interfaces.
There are all good values​​, but I have a problem.

Do this test:
With X1 and X2 still attached, measure the voltage between pin 18 and pin 5. This should be among the 1.25V (essentially 0V). Now measure the voltage (between pin 18 and pin 5) again if you connect pin 3 and pin 5 together with a thread (must be 5V). Here's like having four hands required.


I get 2 times and not 5V 0V .... Is this the problem?
==============================================
Dutch:

Ik de Gateway al gecheckt met dit lijst:
http://otgw.tclcode.com/debugging.html en dan OpenTherm interfaces.
Er komen allemaal goede waardes uit maar, ik heb een probleem.

Heb deze test uitgevoerd:
Met X1 en X2 nog steeds verbonden, meet de spanning tussen pin 18 en pin 5. Deze moet onder de 1.25V zijn (eigenlijk 0V). En meet nu deze spanning (tussen pin 18 en pin 5) nog een keer als je pin 3 en pin 5 aan elkaar verbindt met een draadje (moet zijn 5V). Hier heb je dus eigenlijk 4 handen voor nodig.


Ik krijg 2 keer 5V en niet 0V.... Is dit het probleem?

[hvxl]

With X1 and X2 still attached, measure the voltage between pin 18 and pin 5. This should be [below] the 1.25V (essentially 0V). Now measure the voltage (between pin 18 and pin 5) again if you connect pin 3 and pin 5 together with a thread (must be 5V). Here's like having four hands required.

I get 2 times 5V and not 0V .... Is this the problem?

Yes, that's not right. It means either R4 is not connected on either side, or OK1B is constantly on. Do you still see 5V if you disconnect the X1 - X2 loop?

[Chriskras]

The problem was that a resistor(R1) was not connected properly.
He now works perfectly, I just have a lot of error messages 1.
If I managed to flash firmware 4.0b1 I not have them.

But this firmware does not "OK" when you send a command correctly. Why not? And what has changed!

[hvxl]

Interesting. I would not have expected a badly connected R1 to cause the effects you reported.

If you get a lot of error 01 reports with firmware 3.4, you can disable the check with IT=1. But Honeywell thermostats don't normally have that problem. The Remeha Celcia 20 does. With firmware 4.0b1 the IT=1 is not necessary anymore, as you have seen.

With firmware 4.0b1 the gateway confirms commands by returning the command code and the value it parsed. This was changed because some people would send multiple commands or commands from different sources. It was then difficult to determine which command some random 'OK' was a response to.