Alpha/Beta Firmware Versions

Note: The final version of firmware 4.0 has been released. You should not be using these alpha or beta versions anymore, unless you have very special reasons to do so. Please use the regular released version for the latest features and bug fixes.

Disclaimer: The firmware versions provided here are in alpha or beta state. The possibility of bugs is not at all precluded. Use of any of these items is completely at your own risk.

Firmware Image Files

Version PIC Date Size File Downloads
4.0a2 P16F88 Jan 26, 2013 16207 gateway-4.0a2.hex 299
4.0a3 P16F88 Jan 27, 2013 17042 gateway-4.0a3.hex 258
4.0a4 P16F88 Feb 4, 2013 17153 gateway-4.0a4.hex 245
4.0a5 P16F88 Feb 9, 2013 18119 gateway-4.0a5.hex 286
4.0a6 P16F88 Jul 27, 2013 20599 gateway-4.0a6.hex 243
4.0a7 P16F88 Sep 22, 2013 21524 gateway-4.0a7.hex 235
4.0a8 P16F88 Sep 26, 2013 21679 gateway-4.0a8.hex 247
4.0a9 P16F88 Oct 6, 2013 22079 gateway-4.0a9.hex 236
4.0a10 P16F88 Oct 10, 2013 22276 gateway-4.0a10.hex 265
4.0a11 P16F88 Oct 26, 2013 22313 gateway-4.0a11.hex 305
4.0b0 P16F88 Nov 30, 2013 22296 gateway-4.0b0.hex 275
4.0b1 P16F88 Dec 14, 2013 22337 gateway-4.0b1.hex 318
4.0b2 P16F88 Jan 25, 2014 22447 gateway-4.0b2.hex 244
4.0b3 P16F88 Feb 7, 2014 22603 gateway-4.0b3.hex 290
4.0b4 P16F88 Apr 5, 2014 23167 gateway-4.0b4.hex 272
4.0b5 P16F88 May 11, 2014 23212 gateway-4.0b5.hex 449

Please report any problems with this firmware at the Domotica Forum.

OpenTherm Monitor

Operating system Version Date Size File Downloads
linuxLinux-x86 4.1b2 Jun 28, 2014 4765317 otmonitor 256
R-Pi linuxLinux-armhf 4.1b2 Jun 28, 2014 4362665 otmonitor.ahf 274
Win32Windows 4.1b2 Jun 28, 2014 6538942 otmonitor.exe 562
zipSource 4.1b2 Jun 28, 2014 277114 otmonitor.zip 270

In case of problems with this version, older Opentherm Monitor Beta Versions are still available.

Changes since 3.4

Firmware 4.0a2

  • The message handling part of the firmware has been completely reorganized. This makes message processing more consistent and simplifies adding special treatment for more messages.
  • To avoid accidental blacklisting of supported messages, DataID's are not considered unsupported until the boiler responds to the message with Unknown-DataID three times in a row.
  • Exclude DataID's listed as mandatory in the opentherm specification from ever being blacklisted, even if the boiler responds with Unknown-DataID three times in a row.
  • The gateway will autonomously generate opentherm messages towards the boiler if no opentherm compliant thermostat is connected.
  • When the thermostat wires are short-circuited, the gateway will instruct the boiler to start heating. This allows the gateway to be used with an on/off thermostat.
  • With boilers that do not support the remote boiler parameter DataID's (6, 48, 49, 56, and 57), the gateway will simulate at least read support. In this case the values provided via the SH and SW serial commands are returned to the thermostat.
  • Stop sending the Celcia setpoint in DataID 9.
  • New serial command 'CS' to allow manipulation of the control setpoint being sent to the boiler in DataID 1 messages.
  • New serial command 'MM' to configure the Maximum Relative Modulation Level to send to the boiler in Write-Data requests for DataID 14. Valid values are 0 to 100. Clear the setting by specifying a non-numeric value, for example: MM=T
  • New serial command 'TQ' for buggy Remeha iSense thermostats that will not overrule a remote setpoint by a program setpoint change if, in addition to the program change priority bit, the manual change priority bit is also set in a DataID 100 message.

Firmware 4.0a3

  • New serial commands 'SR' and 'CR' to set and clear responses towards the thermostat. The SR commands takes a DataID and one or two byte values to return to the thermostat for that DataID. The 'CR' command only takes the DataID number to clear. Examples: "SR=18:1,230", "SR=70:14", "CR=18".

Firmware 4.0a4

  • Not all boilers will echo the data in write requests for message IDs they don't support. So the old method of only storing the data bytes in responses doesn't work so well. For write-data messages, the data is now taken from the request.
  • Initial steps at working around Remeha iSense issues.

Firmware 4.0a5

  • Support for a DS18B20/DS18S20 outside temperature sensor to be connected to the GPIO connector: pin 1: GND, pin 2: DQ, pin3 Vdd. In addition a 4k7 resistor is required between DQ and Vdd.
  • LEDs flash on powerup of the gateway (after about 1 second).

Firmware 4.0a6

  • Experimental Opentherm Smart Power support. With this feature you don't need batteries in the iSense aymore for the backlight to work. There is also an associated new LED function: "P", that will light the LED whenever the thermostat requests a raised power level.
  • New GPIO function: The GPIO pins can now be used to drive up to two more LEDs.
  • New GPIO function: Set the room setpoint to a fixed temperature based on an input signal. For example, if your security system has an output that can indicate when the system is armed, you can automatically lower the setpoint when you arm the security system upon leaving the house.
  • GPIO functions can be configured via serial commands: GA=# for GPIO port A, and GB=# for GPIO port B. The following functions are available:
    1. No function, default for both ports on a freshly flashed chip.
    2. Ground - A permanently low output (0V). Could be used for a power LED.
    3. Vcc - A permanently high output (5V). Can be used as a short-proof power supply for some external circuitry used by the other GPIO port.
    4. LED E - An additional LED if you want to present more than 4 LED functions.
    5. LED F - An additional LED if you want to present more than 5 LED functions.
    6. Setback, low active - Set thermostat to setback temperature when pulled low.
    7. Setback, high active - Set thermostat to setback temperature when pulled high.
    8. DS1820 (GPIO port B only) - Data line for a DS18S20 or DS18B20 temperature sensor used to measure the outside temperature. A 4k7 resistor should be connected between GPIO port B and Vcc.
    The GPIO port configuration is stored in EEPROM so it will survive a power interruption.
  • New SB command to configure the setback temperature. Initial setting is 16°C. The current setting can be obtained with the 'PR=S' command. The setback temperature is stored in EEPROM so it will survive a power interruption.
  • The 'PR=G' command has been changed to report the GPIO pin configuration settings. The command returns two digits that indicate the configured functions for GPIO port A and port B respectively. The operating mode of the gateway can now be requested using the 'PR=M' command.
  • Work-around many of the iSense quirks/bugs/misfeatures:
      A remote override setpoint cannot be changed
      The gateway will first cancel any existing remote setpoint before setting the new one.
      Manual change of a remote override setpoint restarts the schedule
      When a manual change is detected, the gateway will continue to send the override setpoint so the iSense doesn't resume the schedule.
      Program change does not override a temporary remote setpoint
      The iSense uses the previously received remote override function (MsgID 100) bitmap at the time the remote override setpoint (MsgID 9) is set. Just like with the remote override setpoint, it doesn't update the remote override function when it receives a new bitmap. The gateway uses the same trick as with the remote override setpoint: After sending the new remote override function bitmap, it cancels the remote override setpoint and sets it again.
      Note that the iSense only requests the remote override function about once every 12 minutes. So it may take that long before a remote override is fully instated.
    Note: These work-arounds will only be applied if a Remeha iSense thermostat has been detected. So owners of other thermostats will not suffer the negative side-effects (like temporarily canceling the remote override setpoint) of these work-arounds.
  • Auto-detect the Remeha thermostat type and apply the relevant work-arounds. There is no more need to use the Remeha-specific TR or TQ commands. In fact, those commands are not accepted anymore.
    Note: Detection of the thermostat type (especially with a Celcia20) takes some time, so sending a setpoint command soon after a power failure or reconnecting the thermostat may not work correctly.
  • Greately relaxed the checks performed on the received opentherm signal. It turns out that some equipment, notably Intergas boilers, are totally unable to meet the Opentherm specifications, especially when the flame is on. The Opentherm specification defines that a bit should be 1ms -10%/+15%. On an Intergas boiler they were found to frequently be almost 1ms +25%. The gateway now accepts bits of 1ms -25%/+50%
  • Due to the more relaxed timing checks, non-significant level transitions will never be considered to be at the wrong time anymore. The definition of Error 01 has been changed to indicate a bouncing opentherm signal, i.e. a signal that rapidly changes several times between the two logical levels.
  • Implemented the possibility to reset/reboot the gateway using the serial command 'GW=R'.

Firmware 4.0a7

  • You can use the 'PR=R' command to determine which thermostat the gateway thinks is connected. It will report:
    1. Default, not a Remeha thermostat
    2. Remeha iSense
    3. Remeha Celcia20
    4. Other Remeha thermostat
  • The IT command has been reintroduced to enable or disable the check for a bouncing opentherm signal. Reports from users indicate that there is quite a bit of equipment out there that apparently isn't able to produce clean transitions. So the check is initially disabled when you flash the firmware. Use 'IT=0' to enable it.
  • Some boilers (like the Hitachi RWM-2.0FSN3E) acknowledge all opentherm messages from the thermostat, instead of returning Unknown-DataId for messages they don't support. This deprives the gateway from the opportunity to inject its own messages towards the boiler. Two new commands UI (unknown ID) and KI (known ID) have been added that let the user configure which messages don't need to be sent to the boiler and can be replaced by alternatives. This configuration is stored in EEPROM so it will survive a power interruption. Some good candidates for messages ID's that boilers don't normally have any use for are: 9 (remote override room setpoint), 20, 21, 22 (date and time), and 100 (remote override function). Also, if the boiler consistently returns 0 for message ID's 18 (water pressure) and/or 27 (outside temperature), it is safe to assume it doesn't actually support those message ID's either.

Firmware 4.0a8

  • New command 'PR=P' to print the current power level (low, medium, or high) of the opentherm line between the gateway and the thermostat.
  • Unset the outside temperature stored in the gateway with 'OT=99'.

Firmware 4.0a9

  • Correctly display byte values above 199.
  • Send the values specified by the SW and SH commands to the boiler without waiting for the thermostat to issue a write command.
  • Command confirmations report the command code and the value that was used. For example: OT=14.865 → OT: 14.87

Firmware 4.0a10

  • Run less easily into serial buffer overrun issues and don't hang up the serial port in case it does happen. There is also a new error code 'OE' when an overrun error happens in a command.
  • PR=O reports C/T/N in lowercase when a requested setpoint override is not yet confirmed and in uppercase once it is accepted by the thermostat.

Firmware 4.0a11

  • Ignore spikes generated by what seems to be a second protocol on the opentherm line, seen with Riello and Intergas boilers.

Firmware 4.0b0

  • Don't switch to smart power if the thermostat hasn't indicated smart power support.
  • If the thermostat sends the same message repeatedly, it is probably confused by the response it gets. Just in case the gateway is causing the confusion, it resets itself.
  • New command 'OH=1' to put the Remote Override Function flags in the high byte as wel as the low byte of MsgID 100. Because the opentherm specifications are confusing regarding the correct location of the flags, the OH option is on by default.
  • The 'PR=T' command now reports the state of both the IT and the OH option.
  • Improved transmit buffer administration to prevent losing track of what to send.
  • Repeat messages during thermostatless operation until an answer is received.
  • The Celcia 20 needs to be informed of a Remote Override Setpoint using an unusual method. So far, the gateway only tried this once. If the Celcia failed to recognize the request, the setpoint would not be changed. Now the Celcia also gets several chances.

Firmware 4.0b1

  • The gateway will now reset after the same message has been repeated for more than 1 minute, while in 4.0b0 it would reset after 32 repeated messages. With 4.0b0 it would also continue to reset itself every minute if the boiler was switched off (e.g. for maintenance). Since 4.0b1 the gateway needs to see successful communication before the communication failure detection is enabled after a reset.

Firmware 4.0b2

  • Prevent an unpowered USB->TTL serial converter from repeatedly resetting the gateway.
  • A continuous BREAK condition on the serial interface should not stop the gateway from handling opentherm messages.
  • When the boiler returns Unknown-DataID for a vendor specific message ID, that message ID is not removed from the list of alternatives.
  • Fix for a problem that under specific circumstances the gateway would keep resetting the thermostat clock to midnight.

Firmware 4.0b3

  • New command 'VS' for overriding the Ventilation Setpoint the gateway will send to the slave. The command takes an integer argument representing a percentage, e.g.: VS=10.
  • Under certain circumstances, it could take more than half an hour before a setpoint change would be applied on an iSense RF thermostat.

Firmware 4.0b4

  • New CH command to control the CH enable status bit when overriding the control setpoint. By default the CH enable bit is set after a CS command with a value other than 0. With the CH=0 and CH=1 commands, the bit can be manipulated.
  • New PM command to specify a one-time priority message to be sent to the boiler at the first opportunity. If the specified message returns the number of Transparent Slave Parameters (TSPs) or Fault History Buffers (FHBs), the gateway will proceed to request the TSPs or FHBs.
  • The gateway will make sure detailed fault information is requested from the boiler when it indicates a fault condition.
  • Powered Opentherm converters may make the line logical high when no thermostat is connected. The gateway now correctly recognizes that situation. A logical low level must be detected before the thermostat is considered to be reconnected.
  • Debug information (specified with the DP command) is now also printed after receiving an incorrect Opentherm message resulting in an error.
  • After an error 2 (incorrect stopbit) or error 4 (parity error), the actual received message is printed, preceded by an 'E'.
  • The override report (PR=O) would print incorrect information after an iSense thermostat had resumed its program or the setpoint was manually modified on the iSense.
  • Fixed the values of the boiler counters in a PS=1 report, which had been rubbish since firmware 4.0b0.
  • The gateway no longer pretends to send its own messages when the thermostat is disconnected in monitor mode.
  • Additional tweak to try and make the gateway work better with a Remeha iSense RF thermostat.

Firmware 4.0b5

  • Improved detection of unusual signals on the serial receiver. Neither a continuous space, nor a 50Hz wave is allowed to have any significant impact on the operation of the gateway.