Rinnai Heating/Cooling Wifi Module

[Mantorok]

Hi @tortfeaser, thanks for the feedback.

The plugin is expecting the temperature only (ie. a number) to be in the payload. I’m not sure if its possible or not but maybe HA’s templating might allow you to pull out the temperature from that zigbee payload and then publish just the temperature figure under a different topic. Then you can subscribe to that topic in the plugin. See https://www.home-assistant.io/docs/configuration/templating/

Another option, I could enhance the plugin to allow you to specify a JSON path to pull out the temperature from the payload.

Regards

[groutley (Glen Routley)]

@Mantorok I really like the sound of adding a JSON path to pull temperature from a payload, this may benefit many of us, as the lack of temperature is certainly annoying, it’s almost embarrassing when Siri says “OK, heating from 0 degrees to 19 degrees”
;-/

[Mantorok]

No worries, I’ll add this enhancement into the next version of the plugin. I’m hoping to release it this weekend if all goes well.

[tortfeaser (Marc Kelly)]

Thanks @Mantorok. That would be awesome. MQTT remains a mystery.

[FrontBottom (FB)]

Howdy

You could try a similar approach to this: Rinnai Heating/Cooling Wifi Module

In your case, create an automation that fires whenever your temp sensor publishes, and then call a script in that automation that extracts just the temp value, and publishes it.

[tortfeaser (Marc Kelly)]

Hi Chris, that’s super helpful.

FWIW, I now have a script:

  sequence:
  - service: mqtt.publish
    data_template:
      topic: hassio/current_temperature/inside
      payload_template: '{{ states("sensor.xiaomi_tempsensor_3_temperature") }}'
  - service: mqtt.publish
    data_template:
      topic: hassio/current_temperature/outside
      payload_template: '{{ states("sensor.xiaomi_tempsensor_1_temperature") }}'
  mode: single
  alias: Publish current temperature

And an automation:

  alias: Publish current temperature
  description: 'Publishes temperature to MQTT topics hassio/temperature/inside and
    hassio/temperature/outside  '
  trigger:
  - platform: time_pattern
    minutes: /1
  condition: []
  action:
  - service: script.publish_temperature
    data: {}
  mode: single

Works great.

[Mantorok]

Version 3.2.0 of the plugin has been released. This version includes the following changes:

• New option to show module’s status in logs & other minor improvements
• JSONPath option to extract temperature from JSON payload for MQTT Current Temperature Subscription
• Show module’s fault status in the log and publish to MQTT
• Pushover notifications for temperature exceeding thresholds, connection errors, faults & incorrrect day/time
• [FIX] Handle status when in “None” mode (ie. when controller is in Settings mode)

@tortfeaser, I know you have a work-around for setting the current temperature but you can now define a JSONPath to extract the temperature from the JSON payload. For you it would be: $.temperature

The fault status reporting is a bit of an experimental feature as I’ve not seen an example of an actual fault on my Brivis HVAC so I’m going by the API doc.

If anyone is interested in receiving push notifications you’ll need to setup a https://pushover.net account and download the app onto your phone. There’s a 7-day free trial but if you still want it after that you’ll need to pay for a one-time in-app purchase. BTW, I’m not affiliated with Pushover in any way.

[Mantorok]

While working on the new version I stumbled upon the mysterious "STM" command (which appears to be used for setting the day and time on the controller).

To see this in the Rinnai status JSON blob you need to enter the “Clock Setting” state either using your controller or sending the command:

N000001{"SYST": {"OSS": {"ST": "C"}}}

The API doc says this is readonly which is incorrect as the above command works. In this state the JSON blob looks like the following:

[{"SYST": {
 "CFG": {"MTSP": "N", "NC": "00", "DF": "N", "TU": "C", "CF": "1", "VR": "0183", "CV": "0010", "CC": "043", "ZA": "Bedrooms        ", "ZB": "Living Areas    ", "ZC": "                ", "ZD": "                " },
 "AVM": {"HG": "Y", "EC": "N", "CG": "Y", "RA": "N", "RH": "N", "RC": "N" },
 "OSS": {"DY": "SUN", "TM": "06:39", "BP": "Y", "RG": "Y", "ST": "C", "MD": "N", "DE": "N", "DU": "N", "AT": "999", "LO": "N" },
 "FLT": {"AV": "N", "C3": "000" },
 "STM": {"DY": "SUN", "TM": "06:39", "SV": "N" } } }]

Note the "STM" at the end and that there is no Heater/Cooler information (which is the reason I included that FIX in the new version as it was causing the plugin to crash).

Unfortunately setting the day or time in the "STM" command doesn’t seem to have any effect on the controller’s day/time. I’ve tried both "Y" and "N" for the value of "SV" thinking it might mean SaVe. Here’s a sample of the command I tried:

N000002{"SYST": {"STM": {"DY": "MON", "TM": "11:00", "SV": "Y"}}}

The changes I send are reflected in the status returned by the Rinnai module but after a short while the controller exits the “Clock Setting” state and the changes are lost.

Just thought I’d mention this in case anyone has any ideas on how this might work or want to experiment for themselves.

[Mantorok]

Version 3.2.1 of the plugin has been released. This contains the following:

• Minor tweaks to Pushover notification events
• [FIX] Plugin doesn’t start properly when controller in Settings mode

I had another crack at trying to set the day and time on the controller (NC-7 Touch) from the plugin but unfortunately I didn’t manage to get it working. I can see the day and time get updated on the controller’s “Clock Setting” screen but I can’t get it to save them unless I physically press the “Done” button.

[Rusti-gotrage (Rus Ti)]

Morning all,

Just noticed - whilst I can turn the fan on and off (when the unit is OFF [not in heat/cool mode]) I’m unable to control the SPEED of the fan, though the speed IS reported by the plugin…

Can’t do it via the HomeBridge accessories page and there doesn’t seem to be any way to do it via HA using the MQTT bridge… (though I could be a n00b and just missing it!)

I thought maybe changing the temperature set-point might adjust it - because turning the dial on the NC6 controller changes the fan-speed when in FAN-ONLY mode, but it didn’t do anything…

[Mantorok]

Hi @Rusti-gotrage,

To adjust the fan speed from the Homebridge accessories page you need to do a long press (ie. hold the left mouse button down) on the fan tile which will pop up a dialog that allows you to control the fan speed.

As for MQTT there is the hvac/fan_mode/set topic that can be set to “low”, “medium” or “high” which roughly translates to 33%, 66% or 100%

[FrontBottom (FB)]

What is this:

@Mantorok

Homebridge accessories page

… you speak of? All of a sudden I feel I have been missing something this whole time …?

[Mantorok]

If you put Homebridge into “Insecure” mode you’ll see another tab (next to Config) named “Accessories” which will show a bunch of tiles for your various Homebridge accessories.

To put Homebridge into “Insecure” mode go into Settings and under the Startup Options turn on the "Homebridge “Insecure” Mode / Enable Accessory Control -I" option and restart.

You can even add them as widgets on the Status screen

[Sabellwind]

Hi @Mantorok. I’ve been a long time lurker when this thread first emerged a year ago. I’ve since changed my entire evap unit and set up an NC-7 and Rinnai touch wifi module. This really shows the power of open source development and I’m very thankful you came around to give this a crack!

Everything works great, my only criticism would be that it’s hard to tell if the unit is in auto mode by just looking at home assistant. Whenever I turn on auto mode via the Hass switch, the switch turns itself off. It’s also not clear in the thermostat, whats happening at any given time in regards to auto mode.

At least with manual mode, you can see the fan, pump and manual mode switches staying constant.

Right now, I’ve got it on auto mode and the comfort level at max (I did this by setting the thermostat to full in the Lovelace card). The cooler is cycling through turning on and off based on comfort setting. This is my view in hass:

Happy to supply logs etc to help.

[Mantorok]

Hi @Sabellwind,

I’m not that familiar with HomeAssistant and I don’t have an Evap cooler but I’ll try my best to help you.

One thing to be aware of is that what the HomeKit thermostat calls AUTO mode is different to what Brivis/Rinnai calls AUTO mode. The one in the HK thermostat is supposed to be used for setting a temperature range and the controller will then automatically switch the mode to heating or cooling as appropriate.

The Brivis controller doesn’t support this type of operation. For Evap cooling the AUTO mode is used to allow you to select a comfort level.

My plugin hijacks the HK AUTO mode and uses it to put the Brivis controller into its AUTO mode. Once it’s done this the plugin then switches the mode back to HEAT or COOL. I think (and I may be wrong here) this is what you are seeing in HA when you turn on AUTO mode and it switches back off shortly afterwards.

If you don’t like this behaviour you might be able to remove the AUTO option on the thermostat by unchecking the “Show AUTO option” in the Homebridge settings. As I don’t know much about HA I’m not sure if it will do anything. If you do try this you’ll need to also check the “Clear accessory cache” option and restart Homebridge before it will take effect. Once it’s restarted remember to uncheck the “Clear accessory cache” option.

Hope that helps.

[Rusti-gotrage (Rus Ti)]

Hi @Sabellwind

I stopped using the Auto mode on the thermostat.
I’ve got an NC-6 unit with refrigerated cooling and heating on it. The Thermostat never changes from HEAT to COOL or back again unless you do it manually… UNTIL I started using HomeAssistant with @Mantorok 's awesome plug-in!

Now I keep the Thermostat in MANUAL and use Node-Red to switch from HEAT to COOL or back again depending on the temps being recorded in the house. I also told Node-Red to NOT run the HVAC if any of the perimeter doors are open, or if no one is home…

The AUTO mode in the Thermostat is redundant when HA/HomeBridge/Node-Red is handling it all for me

G’luck with your set-up!

[Sabellwind]

Thanks for the clear explanations @Rusti-gotrage, @Mantorok.

I’m thinking of going down Rusti’s path and just keeping it in Manual mode, with a series of automations/scripts to basically make it work like a thermostat.

Since reading your replies and playing around a bit more with the behaviour, here’s what I found to be the case for HA (I’ve renamed some switches from the default naming):

1. Turning the manual mode switch off, no matter what the switch’s state is, will activate Rinnai AUTO mode

- service: switch.turn_off
  entity_id: switch.ac_manual_mode

2. Turning off the climate entity in HA turns off the entire unit

- service: climate.turn_off
  entity_id: climate.ac_heatercooler

3. This is a weird one - when in Rinnai AUTO mode, I’m trying to adjust the comfort level by moving the thermostat dial. Reading above posts, it’s clear that in Homebridge, lower thermostat = lower comfort level in Rinnai. HOWEVER, this is inverted in the HA integration. Furthermore, when adjusting the thermostat within HA, it’ll commit the change to Rinnai, but then take on the inverted Homebridge thermostat setting. Here’s how I’m observing it step through:
   Set to 30 in HA:
   
   HB is set to 30:
   
   HB realises it’s actually inverted and changes to 8:
   
   HB sets Rinnai comfort level to full:
   
   
   
   HA gets told to move back to 8:
   

What’s happening in 3. makes for a struggle to get this wife approved It would be nice for this to be synced up so that we can use the auto mode as originally intended, but in lieu of that, I’m still happy having HA control it with some scripting, as @Rusti-gotrage is suggesting.

[Mantorok]

Hi @Sabellwind,

In an earlier post (see post #550) I gave 2 options for how the thermostat dial in Homebridge could work with Rinnai’s Comfort level setting:

1. Increasing the temperature on the thermostat will increase the comfort level. So the temperature dial works similar the comfort level dial on the controller (but it may seem odd that a high temp on the thermostat lowers the ambient temp)
2. Increasing the temperature will decrease the comfort level. This option gives a more realistic representation of how the temperature dial affects the ambient temperature of the house.

Option 2 was selected by @currest2620 which is why it works that way.

What I could do is add another option to the plugin settings that allows you to select how the temperature dial will affect the comfort level. Essentially you can choose option 1 or 2 for yourself.

Let me know if you think that would be useful.

[Sabellwind]

Hi @Mantorok. I think the option to choose given in the Homebridge settings would work perfectly. While you were replying I finished writing up an if-else template that basically inverts the values. It works well, but would definitely prefer it be the right way around from the beginning.

[Mantorok]

No worries @Sabellwind,

It shouldn’t be too difficult to implement this.