Rinnai Heating/Cooling Wifi Module

Feature Requests
301

Thanks for that info @FrontBottom. I’ll add support for a Common zone but there will be no switch to turn it on/off. That should fix @aquavass’s issue with not seeing a switch for Zone A. As for the mode switching I’m currently making major changes to the way the plugin interacts with the module so hopefully it will resolve that.

If anyone wants new MQTT topics now is the time to get your request in. I’m hoping to finalise the new version in the next few days. Maybe even tomorrow if I can get enough spare time.

302

Hey @Mantorok - With regards to the MQTT functionality, I think the only missing topics is for Zones On/Off. The Home Assistant MQTT Climate Thermostat card seems to be working ok, with the exception of status delays. Understand this might be a major rewrite or problematic, but it would go a long way to making the plugin more usable when integrated with other platforms.

I’m struggling to get an MQTT Heat, Cool, and Fan on/off ‘switch’ working in HA which I need for the custom GUI. I was able to get rid of the double quotes I was seeing by using value_template: "{{ value_json }}", however I need a template that detects the off state (i.e. heat = ON, anything else is OFF). If anyone has an idea on how to achieve this, let me know. Otherwise, would it be much effort to add an MQTT topic for Heat/Cool/Fan ON/OFF?

With regards to the plugin, do you plan to add Zone state to show in HomeBridge also? I actually found a quirk of the module response yesterday. When you switch a Zone off, the Zone state does not change. It just remains as the last state, whether it is heating, cooling, or idle. I checked the debug and can see the the module returns: "ZAO": {"UE": "N" } & "ZAS": {"AE": "Y", "MT": "999" } (Zone A Off & Zone A Calling for Heat). Has anyone else noticed this?

I managed to got hold of a Brivis NT-1 remote sensor for my Zone 3, which I’ll hopefully be able to wire up in the next few weeks. Will be interesting to see if it picks it up as another accessory or attribute in the module/plugin.

EDIT: Forgot to mentioned there’s no Manual / Automatic mode switch topic either.

Cheers,
David

303

Thanks @Mantorok, really appreciate it. Just to confirm that Common Zone cant be switched on and off and a Zone A will pop up which can be controlled, As per David_M comments MQTT for Zones will be awesome… thanks!

304

@David_M. You can use Node Red to subscribe/publish MQTT messages and update custom switches entities based on the MQTT calls… I have set up to schedule to switch on the heater … import the following node red flow as an example of the calls you can make via MQTT… a bit messy but should work

[{“id”:“be405609.293978”,“type”:“mqtt out”,“z”:“a5040b9a.03aa78”,“name”:“Switch Heater ON”,“topic”:“homeassistant/brivis/ha/mode/set”,“qos”:"",“retain”:"",“broker”:“cef5e894.160838”,“x”:730,“y”:340,“wires”:[],“info”:“msg.payload=“heat””},{“id”:“f139997.cb83368”,“type”:“inject”,“z”:“a5040b9a.03aa78”,“name”:“Start 7:00 Weekday”,“topic”:"",“payload”:"",“payloadType”:“date”,“repeat”:"",“crontab”:“00 07 * * 1,2,3,4,5”,“once”:false,“onceDelay”:0.1,“x”:160,“y”:340,“wires”:[[“1c6cf564.efafcb”,“c01fa1c4.a4c1e”]]},{“id”:“1c6cf564.efafcb”,“type”:“function”,“z”:“a5040b9a.03aa78”,“name”:“Payload “heat””,“func”:“msg.payload=“heat”\nreturn msg;”,“outputs”:1,“noerr”:0,“x”:490,“y”:340,“wires”:[[“be405609.293978”]]},{“id”:“c01fa1c4.a4c1e”,“type”:“delay”,“z”:“a5040b9a.03aa78”,“name”:"",“pauseType”:“delay”,“timeout”:“5”,“timeoutUnits”:“seconds”,“rate”:“1”,“nbRateUnits”:“1”,“rateUnits”:“second”,“randomFirst”:“1”,“randomLast”:“5”,“randomUnits”:“seconds”,“drop”:false,“x”:470,“y”:440,“wires”:[[“617b061e.8ac0e8”]]},{“id”:“617b061e.8ac0e8”,“type”:“function”,“z”:“a5040b9a.03aa78”,“name”:“Set 20 Degrees”,“func”:“msg.payload=“20”\nreturn msg;”,“outputs”:1,“noerr”:0,“x”:690,“y”:440,“wires”:[[“2f3be1bb.60b5ce”]]},{“id”:“2f3be1bb.60b5ce”,“type”:“mqtt out”,“z”:“a5040b9a.03aa78”,“name”:“Set Temperature”,“topic”:“homeassistant/brivis/ha/temperature/set”,“qos”:"",“retain”:"",“broker”:“cef5e894.160838”,“x”:940,“y”:440,“wires”:[],“info”:“msg.payload=“21"”},{“id”:“26395e6a.ec8992”,“type”:“inject”,“z”:“a5040b9a.03aa78”,“name”:“Start 8:20 Weekend”,“topic”:”",“payload”:"",“payloadType”:“date”,“repeat”:"",“crontab”:“20 08 * * 4,0”,“once”:false,“onceDelay”:0.1,“x”:160,“y”:480,“wires”:[[“1c6cf564.efafcb”,“c01fa1c4.a4c1e”]]},{“id”:“cef5e894.160838”,“type”:“mqtt-broker”,“z”:"",“name”:"",“broker”:“192.168.1.45”,“port”:“1883”,“clientid”:"",“usetls”:false,“compatmode”:false,“keepalive”:“60”,“cleansession”:true,“birthTopic”:"",“birthQos”:“0”,“birthPayload”:"",“closeTopic”:"",“closeQos”:“0”,“closePayload”:"",“willTopic”:"",“willQos”:“0”,“willPayload”:""}]

305

@David_M, I will try to add the following MQTT topics which should help solve your problems. Each will have a value of “on” or “off”.

switch/zone/X (where X is a, b, c or d)
switch/heat
switch/cool
switch/evap (probably not relevant to you but maybe to others)
switch/fan
switch/manual

There will probably be a “/set” and “/get” appended for each of those.

I was also going to rename the current topics slightly, by replacing the “ha” at the beginning with “hvac”. Would that cause any dramas?

Still not sure about how to show the Zone state in Homebridge. One option could be to have a thermostat per zone in the same way a Multi Set Point system works. That way the dot where the temperature is shown would be associated with a specific zone. Did you have any ideas on how it could be represented in Homebridge?

BTW, I also have the same issue where the AE value for a zone is “Y” even though the zone is off (ie. UE = “N”) when the furnace is on. I suspect this may only work for Multi Set Point systems.

EDIT: I think I’ve managed to sort out the updating of the status by making the plugin more event driven. It will require an always on TCP connection which I’ve allowed via a config option but I don’t know how stable it will be since the module seems to reboot itself once a day. Also in the API doc there is the following:

If no response from the client that initiates the connection is received within the TCP timeout time (TTCPOUT), the N-BW2 will terminate the connection and perform a reboot.

The TTCPOUT is set to 5 min.

1 Like
306

@aquavass, that is correct. There will be no switch available for the Common zone, only zones A to D (if enabled according to the module’s status)

307

Awesome Thanks

308

Just thinking about zone handling via MQTT - I was just looking at the MQTT coming for my setup (when in Heating). All my Zones (A-D) are set to off, yet messages I get when the heater is “On” (as opposed to idle) suggest all zones are on (even though as per Home app, plugin knows the correct state).

i.e

[6/14/2020, 10:15:14 AM] [Rinnai Touch] [INFO] Publish: homeassistant/brivis/ha/action/get, Payload: {"A":"heating","B":"heating","C":"heating","D":"heating"}
[6/14/2020, 10:15:14 AM] [Rinnai Touch] [INFO] Publish: homeassistant/brivis/ha/fan_mode/get, Payload: "low"
[6/14/2020, 10:15:14 AM] [Rinnai Touch] [INFO] Publish: homeassistant/brivis/ha/mode/get, Payload: "heat"
[6/14/2020, 10:15:14 AM] [Rinnai Touch] [INFO] Publish: homeassistant/brivis/ha/temperature/get, Payload: "21"

vs

[6/14/2020, 10:18:44 AM] [Rinnai Touch] [INFO] Publish: homeassistant/brivis/ha/action/get, Payload: {"A":"idle","B":"idle","C":"idle","D":"idle"}
[6/14/2020, 10:18:44 AM] [Rinnai Touch] [INFO] Publish: homeassistant/brivis/ha/fan_mode/get, Payload: "low"
[6/14/2020, 10:18:44 AM] [Rinnai Touch] [INFO] Publish: homeassistant/brivis/ha/mode/get, Payload: "heat"
[6/14/2020, 10:18:44 AM] [Rinnai Touch] [INFO] Publish: homeassistant/brivis/ha/temperature/get, Payload: "21"

Does it need to be able to report multiple states? (Which would be sub-states of “On”) e.g Off, On-Heating, On-Idle, On-Cooling …?? - or is it enough that overall system is in “Heat” mode, and a Zone is then either Off, Idle or On?

309

Thanks for this idea Jason - I’ve got a similar setup with Xiaomi sensors. I decided to trigger my temperature publishing based on receiving an MQTT update from the plug-in when in heat mode.

- id: mqtt_publish_livingroom_temp
  alias: Brivis - Publish Temps to Climate.MQTT
  trigger:
  - payload: '"heat"'
    platform: mqtt
    topic: homeassistant/brivis/ha/mode/get
  action:
  - service: script.publish_brivis_temp

For anyone else playing along at home, my current climate setup:

- platform: mqtt
  name: Brivis Heating
  modes:
    - "off"
    - "heat"
    - "fan_only"
  fan_modes:
    - "high"
    - "medium"
    - "low"
  temperature_command_topic: "homeassistant/brivis/ha/temperature/set"
  temperature_state_topic: "homeassistant/brivis/ha/temperature/get"
  temperature_state_template: "{{ value_json }}"
  current_temperature_topic: "homeassistant/current_temperature/living"
  current_temperature_template: "{{ value_json }}"
  fan_mode_command_topic: "homeassistant/brivis/ha/fan_mode/set"
  fan_mode_state_topic: "homeassistant/brivis/ha/fan_mode/get"
  fan_mode_state_template: "{{ value_json }}"
  mode_command_topic: "homeassistant/brivis/ha/mode/set"
  mode_state_topic: "homeassistant/brivis/ha/mode/get"
  mode_state_template: "{{ value_json }}"
  precision: 1

Note - I don’t handle Zones as of yet - hopefully that should change soon with Mantorok’s planned MQTT updates …

1 Like
310

Thank @aquavass. Something’s up with the formatting when importing that flow, but I think I get what you mean. You can use an input.boolean swich with the MQTT out node to publish commands and in MQTT in when the status is received. That would work.

@Mantorok… sounds good. Easy to change any hard coded topics if you do end up changing them.

311

@FrontBottom, I am going to address that issue in the next version so that if a zone is OFF and the heater is ON it will show as “off” in the payload.

Eg. If zone A is off and zone B is on and the heater furnace is on the payload would look like:

{A: “off”, B: “heating”}

1 Like
312

Thats amazing David. @ 10k i’ve just had a 4 zone brivis (Rinnai) system with the NC7 touch and touch wifi installed. I’d love to be able to use your floorplan solution, i had no idea you could use floorplan like that. I’m not a wizz like you but keen to give it a crack. Cheers Rob

313

Version 2.4.1 of the Rinnai Touch plugin has been released. Changes include:

  • New MQTT topics & status change publication event
  • New config options for IP Address, Port & Connection Timeout
  • Add support for Common zone
  • Removal of Map Overrides

This was a major change to the code especially around the handling of TCP connections and sending commands to & receiving status from the WiFi module. I’ve added some TCP connection logging too so you can see when connections open, close & timeout. As well as that I made changes based on information from the API doc which is why there should now be no need for Map Overrides.

I’ve tried to cater for as many different configurations as possible such as heating, cooling, evaporative, single & multiple controllers as well as zones. However, I’m only able to test using my own configuration so cannot guarantee it will work for everyone. If you find a problem post it here or raise an issue in GitHub and I’ll try to fix it ASAP.

As I said this is a major change so expect bugs!

Please provide feedback.

1 Like
314

Awesome - ok @drmcinnes @David_M - time to update and share those MQTT climate sensors … :grin:

315

Yep, I’ve been having a good play with the new version tonight. I’ve configured the sensors and switches.

@Mantorok - One of the first things I’ve noticed is the MQTT publishIntervals config doesn’t seem to be honored. Status updates only appear at HomeBridge startup, and then I only see TCP connections open and close in the log. The sensors and switches only seem to work once I enabled retention in HA. I think you might need to add a ‘retain’ option when publishing updates from the plugin (I’m not sure if this is standard practice for devices??).

Some other feedback - I noticed that commands are consistently 2000ms>. Sometimes it is less. (Pretty sure previously it was usually 1-2secs). Because of the delay, the HA switches send the payload, but the delay causes it to flick back and forth (i.e. click on switch - switch returns to off, then on once the new status is published). I haven’t play with the timeout settings, but would this influence the speed of the commands sent?

Awesome work. Thanks again!

On another note, since upgrading to Home Assistant 0.111, it looks like they have improved the HomeKit integration so that the status updates are fairly quick. Still a bit of a delay, but no longer 60secs.

316

@rgoodworth.home No, worries. I’ll work on generalising it getting it up in to github. I literally just spent 2-3days working out how floorplan works and then it just clicked. Just read the authors notes (GitHub - pkozul/ha-floorplan: Floorplan for Home Assistant). I also got a bit of inspiration from this project: https://www.reddit.com/r/homeassistant/comments/9dmdxm/wall_mounted_tablet_w_floorplan/

317

@David_M, the publishIntervals option should only publish a topic when its payload has changed. It does store a cache of its current topics/payloads to detect if any changes have occurred. There may be a bug there so I’ll take a look. Unless you want all topics to be published regardless of whether they have changed or not.

As for the commands, for me it has always taken ~ 2sec for a command to be sent and confirmed. For changing modes, like heat -> cool, it can take 4 - 5 secs but I’ve seen it take up to 8 sec.

The main problem is the module only sends the status once per second and it typically takes the 2nd status after a command is sent to reflect that command. The plugin checks every 0.5 sec to see if the status has been updated. I could reduce the check interval to 0.1 sec which may shave off a small amount of time if you think it will help.

EDIT: Setting the connection timeout to -1 might also help as it removes the overhead of opening & closing the TCP connection.

318

Thanks. the connectionTimeout setting didn’t make a difference. If you’re planning to reduce the check interval, and might cause an issue, maybe it should be a config option?

Re the status changes, the problem I see is when HA is restarted, the first thing it will do is check the MQTT broker for the current state of the sensors and switches, however these are empty in the broker. I think if all the published /get topics are configured to ‘retain’ it should hopefully fix this as the last state will remain in the broker database.

319

Hey David - interested to know what the Homekit integration does? Are you using the “HomeKit Bridge” integration that puts HA entities back into HomeKit?

320

Chris - Other way round. The HomeBridge Controller integration will sync HomeBridge accessories as entities.

image
image1004×250 29.2 KB