I’ve just released ver 2.3.0 of the plugin which mainly adds MQTT support as well as more coding improvements.
@David_M please let me know if this is what you had in mind. I can tweak it if necessary.
Enjoy
@Mantorok - Fantastic! I’ve done some basic testing of the client by sending some payloads to it and it all seems to be working as expected.
Now I’ve just got to work out the best way to configure an MQTT thermostat in HA. The standard method seems to use topic levels, however it looks like it’s possible to use JSON templates to publish commands also. I’m hoping that publishing MQTT commands will result in status results being returned immediately to provide a more responsive custom interface I’m working on.
During your refactoring, I don’t suppose you come across a method to detect the zone idle state? Per my original observations, when the zone is idle, the AE value is N. I’ve flicked through the API doc @duncan_bayne has generously provided, and can see this attribute is for “Auto Enabled (Calling for heat/cool)”. Turning the zone on/off is the UE value (“User Enabled”). Can we get this status of AE??
Thanks again.
Glad to hear its working for you
The value of the AE state is available from the “CurrentState” key when using the Simple Payload. idle = N, heating/cooling = Y (depending on which mode it’s in)
Alternatively you can access it from the Native Rinnai payload which is what the API document describes
Gotcha. The CurrentState (AE) value is returned in the simple payload, but the ZAS, ZBS, ZCS & ZDS AE value is only returned in the native payload. Hmm… might have discovered an issue (for my system configuration at least).
It looks like the CurrentState value only uses the ZAS/AE status. Therefore, when Zone A reaches set point and the furnace is still on and blowing in Zone B and Zone C, the CurrentState will return to ‘idle’.
Within HomeBridge this means the icon turns to green even when the furnace (or aircon) is on.
The example below is testing my system by ensuring Zone A has reached the set point, but B and C are still heating up.
“ZUS”: {
“AE”: “N”,
“MT”: “999”
},
“ZAS”: {
“AE”: “N”,
“MT”: “999”
},
“ZBS”: {
“AE”: “Y”,
“MT”: “999”
},
“ZCS”: {
“AE”: “Y”,
“MT”: “999”
},
“ZDS”: {
“AE”: “N”,
“MT”: “999”
The Common Zone ZUS/AE status is always N. I’m not sure if I have a common zone parameter configured, or if this makes a difference in your coding.
The default ZonePlus setting of Single Temperature Set
Point also includes an enabled Common Zone for both
Heating and Cooling. The Common Zone and one other zone
must share a common temperature sensor. The default is set
to Zone A (Master Control - sensor ID “n01”).
Does the Rinnai Touch thermostat show this zone status like the NC-6?
Ah I see the problem now. My HVAC set up is similar to yours but if Zone A if Off the value of AE is still Y when the furnace is on. I don’t have a ZonePlus module.
I don’t think I can fix the “Simple” format payloads as its tied to way accessories work, however, I have thought of a possible solution.
What about a 3rd format which allows custom topics and payloads to be defined in the config.json file. You would map a topic to the location in the status JSON blob of the value you want to publish. So you could have something like the following:
Topic: ZoneA/Active
Source: HGOM.ZAS.AE
That way you can cherry pick the data in the status that is important to you. What do you think?
I’ll also look at publishing an updated status after its processed a command. I wasn’t quite sure how you wanted publishing to work. I added the ability to publish at set intervals but wasn’t sure if this would be adequate. I thought about publishing when the value of a state changes but this would require the TCP connection to remain open at all times which I didn’t like given how flaky this can be.
Keep up the good work guys. @David_M I’m looking at going down the MQTT thermostat path too . I started out just making a bunch of individual MQTT sensors, but would be nice to thermostatize it. Keep us posted …
Yeah, I think the custom topics might be the way to go. My limited understanding of MQTT is that we would need to utilise different command topics also. And the post state change status update is important, but yes it might be tricky with the TCP timeout limitations.
This reminds me I’ve got to try isolating the module on it’s own isolated VLAN without internet access - just incase Rinnai send a firmware update down that immobilises the plugin…
@FrontBottom - yep, I got the individual sensors created and had a brief crack at creating a thermostat with the climate: integration. Looks like it should be possible, but the topic levels might be required. I tried with a JSON template for the modes, but it didn’t work.
No worries @David_M. I’ll see what I can do. Do you think you may want a single topic to map to more than one state. I’m thinking in terms of heating and cooling states
E.g. you may want the topic ZoneA/Active to map to both HGOM.ZAS.AE and CGOM.ZAS.AE
I think in regards the zone AE state it wouldn’t matter if it is cooling or heating because the value will be the same, so yeah your example is right.
With regards to the other topics needed, I’m looking at the HA climate integration configuration examples for guidance (https://www.home-assistant.io/integrations/climate.mqtt/). Any suggestions @FrontBottom?
Fraid-knot. TBH my approach was literally to create a bunch of MQTT and Template sensors for every single element. e.g sample
- platform: mqtt
name: "Brivis System"
state_topic: "homeassistant/brivis/status"
value_template: "{{ value_json.Status.System.SystemOn }}"
json_attributes_topic: "homeassistant/brivis/status"
json_attributes_template: "{{ value_json.Status.System | tojson }}"
- platform: mqtt
name: "Brivis Evap"
state_topic: "homeassistant/brivis/status"
value_template: "{{ value_json.Status.System.EvapMode }}"
json_attributes_topic: "homeassistant/brivis/status"
json_attributes_template: "{{ value_json.Status.Evap | tojson }}"
- platform: mqtt
name: "Brivis Heater"
state_topic: "homeassistant/brivis/status"
value_template: "{{ value_json.Status.System.HeaterMode }}"
json_attributes_topic: "homeassistant/brivis/status"
json_attributes_template: "{{ value_json.Status.Heater | tojson }}"
- platform: template
sensors:
# Overall Brivis
brivis_mode:
friendly_name: "Brivis System Mode"
value_template: >-
{% if is_state_attr('sensor.brivis_system', 'HeaterMode',True) %}
Heating
{% elif is_state_attr('sensor.brivis_system', 'EvapMode',True) %}
Evap
{% else %}
None
{% endif %}
brivis_state:
friendly_name: "Brivis System State"
value_template: >-
{% if is_state_attr('sensor.brivis_system', 'SystemOn',True) %}
On
{% else %}
Off
{% endif %}
# Brivis Evap
brivis_evap_state:
friendly_name: "Brivis Evap State"
value_template: >-
{% if is_state_attr('sensor.brivis_evap', 'EvapOn',True) %}
On
{% else %}
Off
{% endif %}
brivis_evap_fan:
friendly_name: "Brivis Evap Fan"
value_template: >-
{% if is_state_attr('sensor.brivis_evap', 'FanOn',True) %}
On
{% else %}
Off
{% endif %}
@Mantorok - I think each available attribute is going to need its own topic, otherwise there will be a lot of templating.
I’ve had a look at that HA link and although the custom format I proposed may go some way to solving your problem I can see potential issues. E.g. in HA switching from mode “fan_only” to “cool” may require up to 3 commands to be sent to the Rinnai Touch module (with appropriate delays between them). I’m thinking a specific HA format may be better so the plugin can send the appropriate commands to the module when it receives a command from HA
Can you please provide a list of the configuration variables you want to use from HA such as “mode_command_topic” and “mode_state_topic” and I’ll see if I can find a workable solution. Can you also include those for controlling the zones
I think you would need to have a topic for all function states (stat/RinnaiTouch/), and for all functions you can command (cmnd/RinnaiTouch/), but I see what you mean about the multiple commands required for some scenarios. I did a quick test by publishing {“FanOn”: true}, and it sent the multiple steps okay, but I assume this is using the existing logic you had, however if you have to create a subtopic for everything, new logic is required to stitch them together.
For my personal use, I just need the state of everything including the zone heating/cooling state, and I can probably use the single RinnaiTouchCommand topic, with an immediate status published. This would let me graph some stats around how often the furnace is running, and the efficiency of each zone.
Yourself and others may have different needs. The request for MQTT support was to bypass the Home Assistant HomeKit Controller integration, which only polls accessory states every 60secs. All your efforts is much appreciated!!
I’ve gone through the list of topics that HA supports for MQTT HVAC and I think these are the ones that apply to the Rinnai Touch. I’ve matched these up with a proposed topic that the plugin could support.
HA Config Variable
action_topic
current_temperature_topic
fan_mode_command_topic
fan_mode_state_topic
mode_command_topic
mode_state_topic
temperature_command_topic
temperature_state_topic
Proposed Plugin Topic
rinnai/action/{zone}/get
rinnai/current_temperature/{zone}/get
rinnai/fan_mode/set
rinnai/fan_mode/get
rinnai/mode/set
rinnai/mode/get
rinnai/temperature/{zone}/set
rinnai/temperature/{zone}/get
where {zone} is A, B, C or D
Valid actions: [“idle”, “heating”, “cooling”]
Valid fan_modes: [“low”, “medium”, “high”]
Valid modes: [“off”, “cool”, “heat”, “fan_only”]
For this to work though you would need to define multiple HVAC’s in HA, one for each zone. Would that work for you (if its actually possible)?
The alternative is to drop the {zone} from the topic and include the zones in the payload (like I implemented for the “Simple” payload) where those topics that relate to zones would look something like:
{A: "value1", B: "value2", C: "value3"}
You then need to use templates to extract the data you want.
I think your alternative suggestion would work fine. Having multiple thermostats would be a pain, unless you had a Multi-Temperature Set Point configuration.
I’m relying on David here 
… can’t get my head around it enough at th emoment to add any value - but happily sitting on the sidelines seeing good progress.
Hi @Mantorok, looks like you have a created a real nice plugin for the Brivis heater which is long awaited. Mate for a NOOB like me I’m struggling to understand how to install the plugin. You mention that you need to install Homebridge first of which I set up the native Homebridge in HA. I can telnet to the HA box which is the standard HA RPi install but does not have the ability to install npm to install your plugin. Am I going about this the right way and and assistance would be greatly appreciated. Thanks!
Hi @aquavass, I actually don’t use HA. I have Homebridge installed in a Docker container running on a NAS. If you haven’t installed Homebridge itself then I would suggest you start here: https://github.com/homebridge/homebridge/wiki There are instructions for installing it on an RPi.
I would strongly recommend installing the “Homebridge Config UI X” with it which gives you a nice Web User Interface from which you can search for, install & configure plugins (including mine).
Hope that helps.
I thought it was integrated into home assistant as I’m looking for a central view on all smart devices… trying not to add more components. Thanks for the update.
Hey @aquavass - If you’re running hass.io on a RPi, which is essentially a custom OS that runs docker to present Home Asssistant and plugins, you should be right to following this guide using the Portainer plugin: Tutorial: add Homebridge to Hass.io using Portainer
Once you have the HomeBridge container up and running, you can open its portal and install the RinnaiTouch plugin, and hopefully it will automatically find your module and automatically create all the thermostat accessories. After that, some of your options of controlling it are:
- Home Assistant HomeKit Controller integration (will create new entities)
- MQTT
- Node-Red HomeBridge plugin
Hope that helps.
1 Like