Opentherm Gateway as zone controller - firmware modification

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

Moderator: hvxl

Opentherm Gateway as zone controller - firmware modification

Postby WvandeHoef » Mon Jan 16, 2017 9:53 pm

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
WvandeHoef
Starting Member
Starting Member
 
Posts: 3
Joined: January 2017

Re: Opentherm Gateway as zone controller - firmware modification

Postby hvxl » Tue Jan 17, 2017 9:28 pm

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
hvxl
Senior Member
Senior Member
 
Posts: 1016
Joined: June 2010

Re: Opentherm Gateway as zone controller - firmware modification

Postby WvandeHoef » Tue Jan 17, 2017 11:31 pm

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: January 2017

Re: Opentherm Gateway as zone controller - firmware modification

Postby WvandeHoef » Sat Jan 28, 2017 8:50 pm

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 1268 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 1268 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?
WvandeHoef
Starting Member
Starting Member
 
Posts: 3
Joined: January 2017

Re: Opentherm Gateway as zone controller - firmware modification

Postby hvxl » Fri Feb 03, 2017 11:29 pm

Adding the caps would definitely be a good first step towards a remedy.
Schelte
hvxl
Senior Member
Senior Member
 
Posts: 1016
Joined: June 2010


Return to Opentherm Gateway Forum

Who is online

Users browsing this forum: No registered users and 1 guest