Opentherm Gateway as zone controller - firmware modification
Posted: Mon Jan 16, 2017 10: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:
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
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
Question: am I manipulating the code on the wrong location, or overlooking something?
Kind regards,
Wouter