Opentherm Gateway as zone controller - firmware modification

This Forum is about the Opentherm gateway (OTGW) from Schelte

Moderator: hvxl

Post Reply
WvandeHoef
Starting Member
Starting Member
Posts: 3
Joined: Mon Jan 16, 2017 10:20 pm

Opentherm Gateway as zone controller - firmware modification

Post by WvandeHoef »

Hi Schelte,

First of all thanks a lot for all the work you have put into this project. I really enjoy working with it!

In the past I have build my OTGW and have modified the assembly code so that the unit controls a relay over one of the GPIO pins to open the valve to my floor heating when the room thermostat is setting its chenable bit. This went fine, until my wife opened a practice that also needed to be heated. I am using an on/off thermostat there that is controlling the anti-freeze input of my Remeha heater/boiler unit. This has now run for a couple of years without a problem. Now I am asked by the kids if I could also heat their rooms when the outside temperature is low. For that I have bought a Rpi 3 and the plan is to write a Python script that leaves the OT room Thermostat control everything, until the outside temperature drops below 15 degrees and then have the script switch the system to outside temp controlled heating by setting the control point and enable the heating.

So far the RPI3 is doing ok, otmonitor has been tweaked to add a few extra parameters to the json output and when I started the first test I found out that I am missing the original status of the room thermostat, as the gateway is overruling the chenable bit. I have tried to work out a solution in the tcl scripts, but as I am not familiar with that language I came up with another approach: if I could mirror the chenable bit from the room thermostat to the ch2enable bit, then the gateway would not mess with that bit and otmonitor would be able to show that info in the json message.

I have tried manipulating the gateway.asm, WHen I manipulate the bits to late in the chain, I mess up everything and when I manipulate them in the beginning it does not work at all....

I am currently focussing on this section, where I check inside the Read-Data code if the Msg-ID = 0 and then if the enable bit in byte 3 is set. If it is, I want to set also the ch2enable bit:

Code: Select all

;************************************************************************
;Process an incoming OpenTherm message (modified by WH)
;************************************************************************
		package	Message
HandleMessage	btfsc	MsgResponse	;Treat requests and responses differently
		goto	HandleResponse

HandleRequest	btfsc	byte1,4		;For Write-Data messages, ...
		call	StoreValue	;... store the value from the thermostat
		movfw	byte1
		movwf	originaltype	;Save the original message type
		movfw	byte2
		xorwf	originalreq,W	;Compare against previous message
		skpz
		clrf	repeatcount	;Message is different -> reset counter
		xorwf	originalreq,F	;Save the original message ID
; modifications to mirror chenable bit to ch2enable bit
		movfw	byte2	;Load byte2 with Msg ID 
		addlw	0x00		;Test for Msg ID 0 (Status) - add 0 will set the zero flag if the outcome is 0
		skpz			;Skip next instruction when zero flag is set
		goto	noch2mods	;not Msg ID 0 (Status) -> no changes
		btfss	byte3,0		;test if chenable is set
		goto	noch2mods	;not set -> no changes
		bsf	byte3,4		;also set ch2enable bit
; end of WH modifications
noch2mods	movfw	byte3		
		movwf	databyte1	;Save original data byte #1
		movfw	byte4
		movwf	databyte2	;Save original data byte #2
		bcf	AlternativeUsed
		bsf	OverrideUsed	;Assume only data values will be changed
		call	TreatMessage	;Process the request from the thermostat
		clrf	boilercom	;Going to send a message to the boiler
		call	UnknownMask	;Check if ID is unsupported by boiler
		skpnz			;Data ID is not known to be unsupported
		goto	SendAltRequest
		btfss	AlternativeUsed	;Was the request modified in some way?
		return			;Send message unmodified to the boiler
		goto	SetParity	;Calculate the parity of the new message
SendAltRequest	bsf	AlternativeUsed	;Probably going to send a different msg
		bcf	OverrideUsed	;Changes will be more drastic
		call	Alternative	;Get the alternative message to send
		btfss	AlternativeUsed
		return			;There were no other candidates
		movwf	byte2		;Fill in the alternative Message ID
		goto	SetParity	;Calculate the parity of the new message
I have no experience with Microchip controllers and their limited ASM code set, it could be that the check for Msg-ID = 0 has been coded wrong, but the only way I know to have the zero flag set is by either add or substract or use an xorlw. I tried them all, but to no avail...

Question: am I manipulating the code on the wrong location, or overlooking something?

Kind regards,
Wouter
hvxl
Senior Member
Senior Member
Posts: 1965
Joined: Sat Jun 05, 2010 11:59 am
Contact:

Re: Opentherm Gateway as zone controller - firmware modification

Post by hvxl »

Yeah, don't do that. The place to modify messages is in TreatMessage. It calls specific pieces of code for different messages. So to modify the status message, you would only have to concentrate on MessageID0. The comment before TreatMessage explains how you can distinguish the stages within the lifetime of a message:

Code: Select all

;Define special treatment based on the message ID. This code will be called in
;three situations:
;1. A request was received from the thermostat.
;2. A response was received from the boiler.
;3. An alternative message has been sent to the boiler and a fake response has
;   been created to be sent back to the thermostat.
;Which of the three situations applies can be determined by checking the
;MsgResponse and BoilerResponse flags. The flags will have the following states:
;1. MsgResponse = 0, BoilerResponse = X
;2. MsgResponse = 1, BoilerResponse = 1
;3. MsgResponse = 1, BoilerResponse = 0
;If the code modifies the message, it must set the AlternativeUsed flag. This
;will cause the parity to be recalculated and the modified message is reported
;on the serial interface.
Since the code already has a different path for case #1, you could implement your idea in only two instructions.

But I think implementing it in OTmonitor would be the cleaner solution.
Schelte
WvandeHoef
Starting Member
Starting Member
Posts: 3
Joined: Mon Jan 16, 2017 10:20 pm

Re: Opentherm Gateway as zone controller - firmware modification

Post by WvandeHoef »

Thanks Schelte!

I will look into that section to see if I can implement it. Tonight I discovered why the above did not work: the bits are set, but the message is already send by PrintRcvdMsg to the serial port before I manipulate the bits....

Initially I tried to do it in otmonitor, but the problem is the 500ms delay that is implemented on the incoming message. Due to that the R message with the changed bits (due to user commands setting the Control Setpoint) is overwriting the T message with the flags I am looking for. Being unfamiliar with ticl I decided to move to a more familiar area ;-)

Speaking of otmonitor: is there a way to add a reload command for the graph screen in the web view? I was looking for an insertion point for a meta-tag (<meta http-equiv="refresh" content="waarde">) or a javascript (location.reload), but I am unable to reverse engineer how this page is build.

Kind regards,
Wouter
WvandeHoef
Starting Member
Starting Member
Posts: 3
Joined: Mon Jan 16, 2017 10:20 pm

Re: Opentherm Gateway as zone controller - firmware modification

Post by WvandeHoef »

I got it working and can now monitor living room and second group individually.
2017-01-28 20_30_28-Opentherm Gateway.png
2017-01-28 20_30_28-Opentherm Gateway.png (51.15 KiB) Viewed 5106 times
But I am now facing a hardware issue: the OpenTherm Gateway is resetting multiple times a day.
2017-01-28 20_48_35-otgw reset.png
2017-01-28 20_48_35-otgw reset.png (10.28 KiB) Viewed 5106 times
Initially I thought it was caused by my sw changes, but even with the original firmware in monitoring mode it happens. As I drive 5 LEDs and the external relais (only the optocoupler, not the coils), I upgraded the transformer to the 130mA version and the regulator to an SMPS version, but the reset still occured. AFter studying the log I found that the reset always occurs within the first 2 minutes after the living room enabled the chenable bit. So I sat close to the gateway for some time to watch the unit reset and then I learned that the reset occurs when the pump of the floorheating is started by the WTH pump switch when its temp sensor detected hot water. To verify that I unplugged the pump switch and plugged it in and again it triggers a reset of the gateway. As this pump is not controlled by the gateway the only link is the mains connection. Both the gateway and the pump are on the same group and phase. Relocating the pump cord to another phase using an extension cord solves the problem, but this is not feasable my application. So I will have to do some filtering on the pcb of the gateway.

Does anyone have some tips?

Will doubling the C1 and C2 elco's and adding a 10nF cap between VCC and GND of the microcontroller do the trick, or do I need an mains input filter as well?
hvxl
Senior Member
Senior Member
Posts: 1965
Joined: Sat Jun 05, 2010 11:59 am
Contact:

Re: Opentherm Gateway as zone controller - firmware modification

Post by hvxl »

Adding the caps would definitely be a good first step towards a remedy.
Schelte
Post Reply

Return to “Opentherm Gateway Forum”