Rinnai Heating/Cooling Wifi Module

Hi @funtastix,
sorry about my big delay… what can I say, life happens!

Now the weather has cooled, it is hard to test the Evap cooling, but I think I have my head around running the evap FAN on its own, (not something I want to do at this time of year).

But, now I am using my heating again, and the ZoneA certainly isn’t working as I would expect,
I have an entity switch.rinnai_touch_zone_a_switch
If I turn it on, it toggles and then returns to off, no matter how many times I try.
It does seem to work, but I cannot get in Sync with the state of the Duct Valve and the switch as the switch always returns to off, Without standing infront of a ZoneA vent I cannot tell if it is open or closed.

I get this in the Debug log, when I turn the ZoneA ‘On’…

2023-05-04 10:52:33.586 DEBUG (MainThread) [pyrinnaitouch.connection] Sending command: N000001{"HGOM": {"ZAO": {"UE": "Y" } } }
2023-05-04 10:52:34.069 DEBUG (Thread-6 (receiver)) [pyrinnaitouch.receiver] Fired off command: (N000001{"HGOM": {"ZAO": {"UE": "Y" } } })

So I gathwer it works, but why does the switch return to OFF, everytime in HA ?

That command seems right for a zoned system with single set point. Are there any more logs? Most interesting will be the next status coming back after the command was fired. And the 2nd one after that, too

Hi, Thank you for your help!

I have captured the Log covering:
10:13 toggle dashboard zoneA switch to ‘on’. it returns to off after approx 1 second.
10:15 - ZoneA has hot air coming out.
10:17 toggle ZoneA Dashboard switch to ‘on’ (as it was showing off) and after 1 second it returns to off.
ZoneA still actually open
10:18 try the same as last step
ZoneA still actually open
10:19 - tap on ZoneA switch to get Entity Detail, showing big switch.
Turn this ON (as it shows Off), it stays ON, so then Turn it off.
zoneA now Actually Closes.

(My sequence above is correct, I am just hoping I remembered the Times correctly, same with my commenting in the log)…
Link to Log:-
https://ibm.box.com/s/4ef4zt9ioz6zmt3xelaxxfsmfdauqth9

Please let me know if I can provide anything else.

I think I can see what is wrong. It’s a small bug in getting the status for single set point zones. I’ll check it out one of the next few nights. Thanks for the logs, that helps on testing it

1 Like

Should be fixed in 0.12.13.

Your box link expired, so I couldn’t test the change, but it seemed pretty obvious.

That is Fantastic funtastix! THANK YOU !!
Yes it works like a charm,
The only problem I still have now, is that I need to ‘reload’ the integration occassionally, to get things working in HA.
My Wiifi module has aweful reception, Despite being 30cm from the Access Point, no matter how many Wifi Routers and positioning I have tried, seems I got a dodgy Rinnia Touch that really is not good at WIFI reception.
Result being that it seems to drop off regularly, when it does, It seems the intergration is not good at picking it up again, and me forcing a reload of your integration from the Devices panel, usually sorts it out.
Not sure if that is a me problem, or something that perhaps could be improved ?
But Thank you so much for the Zone fix in my Single Set Point system !

If you want to send me some logs and details? Do you have a mesh router? In mine I turned off mesh for the Rinnai device to make it way more stable.

@funtastix, Thank you again…
took a little bit for the wifi module to have an issue,
but this morning it was cold in the house!
Heating is Automated to come on at 5:20AM but it did not this morning.
I tried turning on the Heating with HA thermostat at 5:50AM but there was no change from being ‘Off’
I then tried to reload the Device integration around 5:51AM, But no change.
I rebooted the Access Point, and at approx 5:53AM reloaded the Device plugin again.
Viola… it lept into action!
Debug Logs from 5:16AM (pre the Automation turn on attempt at 5:20). thru to around 6AM where everything is working again.
Box (expires 12 June)

I am using Ubiquity Unify network, all hardwaired access points, no meshing.
Previously I used Google Wifi Mesh and the Rinnai Touch Module did similar, with its very weak wifi reception, but recovery just happened without intervention when I used the HomeBridge Plugin.
I am more than happy to try anything to improve the modules Wifi Signal, I have tried most settings on the Unifi UAP-HD but nothing makes a difference, Pre the Google Mesh Wifi I used a DLINK and a LinkSys, but the Wifi to this Module has always been Cr_p!
I feel its wifi antenna must be seriously lacking! I’ve opened the moduleand can’t see a Wifi antena on the board at all ! (maybe its on the back?).

If you can do anything to assist in the Cold wakeups occassionally you will improve the WAF immensely!

I’m not entirely sure what is going on, but something is going on with connectivity. Your Android TV and front door camera seem to also experience problems with being connected to HA, and they fail with a similar error (Bad file descriptor). It looks like network issues to me. The integration actually loses connection a lot until you reboot the router, and it always recovers, but it has fairly long periods offline

Thanks for looking at it, I hoped I had removed all the ring and androidtv entries…
The TV is turned off, hence it is not on the network.
The ring doorbell was down to 1% charge and seemed to drop off continually(maybe power saving).
But the rinia touch as I said, drops off as its RSSI is pathetic and barely has a wifi signal, making it very unreliable on the network, i dont know if my module is a dud, or is it a design issue with wifi reception.
I had issues setting it up when I first got it out of the packaging as it wouldnt pickup the wifi, I now have an access point approx 1 ft from it to give some form of reliability.
What is odd though is, to get it working again, it is usually a case of restart your plugin, and then everything leaps into life again.

noticed there was a new version… and my unit seemed to have a drop out. So I upgraded, all seems ok… but I got this error in the log…
2023-08-02 11:34:15.223 ERROR (Thread-3 (receiver)) [pyrinnaitouch.receiver] Couldn’t decode JSON (probably HELLO), skipping (AttributeError("‘NoneType’ object has no attribute ‘group’"))

hope this helps you…

If that error occurred only once it’s fine. It happens when the unit connects for the first time. Call it lazy coding. Could probably put it on the improvement list.

Hi, having strange issues with my brivis not working in HA…
Log shows:

2023-08-13 15:21:17.503 DEBUG (MainThread) [custom_components.rinnaitouch] Removing controller with IP: 192.168.37.195
2023-08-13 15:21:17.503 DEBUG (MainThread) [custom_components.rinnaitouch.climate] removing entity from hass
2023-08-13 15:21:17.514 DEBUG (MainThread) [custom_components.rinnaitouch] Get controller with IP: 192.168.37.195
2023-08-13 15:21:17.515 DEBUG (SyncWorker_12) [pyrinnaitouch.connection] Error 1st phase during renewConnection [Errno 9] Bad file descriptor
2023-08-13 15:21:17.515 DEBUG (SyncWorker_12) [pyrinnaitouch.connection] Creating new client...
2023-08-13 15:21:27.522 DEBUG (SyncWorker_12) [pyrinnaitouch.connection] Error during renewConnection timed out
2023-08-13 15:21:27.522 DEBUG (SyncWorker_12) [pyrinnaitouch.system] renewing connection failed, ooops
2023-08-13 15:21:27.524 INFO (MainThread) [custom_components.rinnaitouch.climate] Set up RinnaiTouch entity 192.168.37.195
2023-08-13 15:21:27.524 DEBUG (MainThread) [custom_components.rinnaitouch.climate] Ext. temp sensor entity name: sensor.cinema_temperature
2023-08-13 15:21:27.524 DEBUG (MainThread) [custom_components.rinnaitouch.climate] Ext. temp sensor reports: 17.7
2023-08-13 15:21:27.524 DEBUG (MainThread) [custom_components.rinnaitouch.climate] Set up RinnaiTouch zone A entity 192.168.37.195
2023-08-13 15:21:27.524 DEBUG (MainThread) [custom_components.rinnaitouch.climate] Ext temp sensor (A): sensor.0x158d00044f3ded_temperature
2023-08-13 15:21:27.524 DEBUG (MainThread) [custom_components.rinnaitouch.climate] Ext temp sensor reports: 14.38
2023-08-13 15:21:27.527 DEBUG (MainThread) [custom_components.rinnaitouch.climate] Internal temperature sensor reports: 999

Is the issue “[Errno 9] Bad file descriptor” ? And why?

As you may recall, I do get network issues to the brivis touch wifi, but those I can revover from with Access point reboots and briv touch POR, but this one persists, no matter how much I reset things.

Bad file descriptor is network related. It happens when the initial connection is made, but the data cannot be read from the socket (which is a “file”).

Thank you for your reply,
I did find the cause of it…
In my playing to understand why I couldnt get HA talking to the wifi module, I disabled the addon, and started the homebridge plugin, which also was showing no response from the module.
I then disabled the homebridge module again, thinking that was enough, but apparently HB still needed to be restarted to stop that plugin running,
So the bad descriptor I guess is a sign that there is a conflict in communicating to the module.
Ended up that I am getting the time needs setting on the NC-6, if the time is not correct your addon will not communicate. I seem to be hitting that issue every few days.

8m inclined to think your module may be faulty? Without connecting, does it end up in time setting mode?

I disabled the addon after your comment, 10days ago now,
And the NC-6 has not had an issue at all.
It is keeping its time fine and running its programmed schedule without issue.
Not sure how much longer to run this way to prove it is not faulty?

Interesting. Can you send me your schedule? Miners not running on a schedule.

Also, could you run it in manual mode while connected for a while? Maybe it’s the schedule mode that causes some effect and interaction.

Otherwise, with your logs, maybe I can catch that case and try to send a packet to get it back operating normal, but finding the cause would be better

Thanks for your thoughts…
Been a further 3days now so 13 days and no issue at all without the addon running.
I do not run it with a schedule when running it with HA, the schedule currently is on the NC-6 itself running in Auto mode, as that is as good as it gets without any HA controlling it.
When your HA addon is enabled, it runs the heating in manual mode via automations,
E.g. my morning automation:


alias: Enable heating at morning
description: Turn on Brivis if people home
trigger:
  - platform: time
    at: "05:20:00"
    enabled: true
condition:
  - condition: numeric_state
    entity_id: sensor.outdoor_temperature
    below: 12
  - condition: numeric_state
    entity_id: sensor.indoor_temperature
    below: 17
  - condition: state
    entity_id: group.family
    state: home
  - condition: or
    conditions:
      - condition: state
        entity_id: climate.rinnai_touch
        state: "off"
      - condition: state
        entity_id: climate.rinnai_touch
        state: cool
action:
  - service: climate.turn_on
    data: {}
    target:
      entity_id: climate.rinnai_touch
  - service: climate.set_temperature
    data:
      temperature: 18
      hvac_mode: heat
    target:
      entity_id: climate.rinnai_touch
mode: single

I will enable the addon again, and try to capture logs to show the issue,
Problem is I have no idea when it goes to time set mode, until The house is cold in the morning, but it could have happened at any point after 7pm when it turns off for the night, or 5:20am when it should come on.
I note in the bug #84 reported on github NC-6 goes into set time mode · Issue #84 · funtastix/rinnaitouch · GitHub
That in that case appeared to be related with losing connection, which maybe very possible in my case also, given the wifi stength on my brivis wifi module is terrible despite being about 30cm from the wifi AP.

I will see how I go with logs and upload when I think I have caught it.
Would you prefer me to update here or in the github issue?

I never run my HVAC in automatic mode any more.
It’s in manual mode, purely controlled from Node Red within HA.
Has worked reliably this way since day one.