Level 1:
CGOM = "Cooling Operating Mode"
ECOM = "Evaporative Cooling Operating Mode"
HGOM = "Heating Operating Mode"
SYST = "General System Components"
Level 2
CFG = Configuration (/System-Wide Configuration Information)
OOP = Overall Operation
GSO = General System Operation
GSS = General System Status
APS = System Auto-Program Setup
APZ = Zone Auto-Program Setup
PSU = Programming Setup
AVM = Available Operating Modes
SYST
OSS = System-Wide Operating Information
FLT = System-Wide Fault Status
STM = Set Time/Set Day (/Networker Clock Setting)
UST = User Set ..... Clock Format/Temp Display Format/ (/Network User Setttings)
PRM = Networker Parameter Access
Other
HC = HeatingCalled
FS = Fan
GV = GasValve
PH = PreHeat
O = Operation
S = Status
ZAAE = ZoneA AutoEnabled etc
Spot on also with the “Sequence” counter (along wither everything else). Some more observations:
Every message (whether Direct WiFi or via Azure Hub) increments a sequence counter, an integer between 1 and 999999. The “N” seems to be a fixed value for the start of the transmitted message.
It seems to handle a “WiFi” connected mode, and a “Hub” connected mode - which seems to be a cloud based method via Azure IOT Hub (which explains the MQTT libraries I think)
The app listens on port 50000 waiting for that “Rinnai_NBW2_Module” string, and then extracts config information from the rest of that packet “setup”. I think the secret sauce is in that message. e.g the port to talk back the Touch on, passwords and some version info and a key to access the Hub.
“At this stage unfortunately we do not have any information on it being compatible with Google home but we believe that is it currently being worked on.”
For what it is worth - mine came on Friday. Like others have said - real easy install. Just playing around with some packet captures.
Looks like as soon as you make a TCP connection to port 27847, it will soon send through all the current status info. That should make it fairly easy to get status information from it. Still to play around with sending commands …
Edit: Well that was a bit easier than expected. No need to worry about authentication or anything like that. I just sent the appropriate commannds to the Touch directly using ncat, and voilà.
Possibly - what might be better is using the python_script component. I just whipped up the script below to test sending the commands from the command line and it actually worked . Later tonight I’ll try and convert it to an actual python_script component.
Edit: Deleted the embedded code …
Have created a Gist with a first draft/cut at a client (and my first python script …)
Won’t be able to use the python_script component as this sccript needs other libraries which doesn’t work for python_scripts.
Use it like:
$ python MyTouchClient.py 192.168.200.119 --mode heat --action on
$ python MyTouchClient.py 192.168.200.119 --mode heat --heatZone A --zoneAction on
$ python MyTouchClient.py 192.168.200.119 --mode heat --heatTemp 23
or
$ python MyTouchClient.py 192.168.200.119 --mode evap --evapFanSpeed 12 --action on
Excellent work. Sadly neither the script nor sending the commands via ncat work for me - just times out from a 'pi and I get a ‘connection refused’ from a mac. Maybe it’s that sequence number. When I have the chance over the weekend I’ll try to troubleshoot…
Hmm - Shouldn’t be the sequence number … for me I can send as many N000001’s as I like and all commands get accepted … prior to sending commands the script should print out a status message (or at least a HELLO from the Touch) - do you see that?
It sounds like your not even getting a connection.
I’m connected fine to port 27847. I wrote a quite a proof of concept Node Red flow that connects to the touch and monitors traffic bringing any changes into lovelave card. (no commands are sent at this point).
It works fine but it seems to be a heavy load on the touch as it occasionally needs to be rebooted.
Not at this point. It holds the connection open. Which is what I don’t really like.
The node red flow strips out the garbage and formats the steam to valid JSON. Then it was basically a matter of use a JSON diff tool to find out what values change when i triggered a function on the unit.
re response - no, not seeing anything. Did some more troubleshooting and found that although initially (when I first started testing) ports 80 and 27847 were open, just then only 80 was open.
I could get onto the mysimplelink web server, and I was also able to still access the system via the app from my mobile, but then realised it was going via the cloud rather than direct… I’m now finding that the android app is crashing (something a few people have reported on the Google Play store), I suspect - although can’t prove - when it’s trying to switch over from cloud to local direct mode.
Basically - I think my issue is specific to me, maybe by hitting it with too many scans etc local access is broken so will need to reset the module. I’ve tried a reboot without luck, so will try leaving it off for a few minutes - if no good then I’ll do the reset and change it to ‘home direct’ mode then, as I don’t need the cloud access feature anyhow.
…and so tried a reset (turning module off, holding in ‘ap’ button, turning power on and waiting for the wifi light to flash orange), putting it into AP mode and reconfiguring. When I tried direct mode, it would appear to work but the remote would not complete the setup - would crash at the end. Thought maybe it was an android issue so tried an iPhone, and that wouldn’t get to the saving part. Changed to cloud mode and that worked. Did a quick scan with nc, and port 27847 was open again. Fired up the app, and it connected locally. Tried running the script and… no response. Checked the port and it was not responding again. Fired up the app, and it still connected locally.
My best guess now is demonic possession.
Quick question: Do you know of a full reset option other than just the holding in of the ap button until the wifi light flashes ?
(by the way - just worked out that "direct mode’ means you connect directly to the module as an ap - it only supports one concurrent connection. It does not mean, as I initially assumed, that it would connect to the local wifi as a client. Doh.)
I’ve dumped a script that just gets the status and returns a more friendly JSON formatted string. Am trying to work out the best way to get this into HA now, to make this bit actually functional:
This is awesome. If you do get a HASS climate component made, could you give it an option that exposes each zone as a seperate climate device? I think it would make it easier to use Google and HomeKit, as you could say ‘heat upstairs to 24 degrees’ or ‘turn off downstairs’.
I’m happy to have a crack, but it will certainly take a while - been doing python for about a week now No doubt this is where the difference between me hacking something up that works in my case, and a somewhat-professional package (like the Touch APP) will be
For Temp and Zone control, all I can see in the status messages is:
Is the Zone configured/available (ZAIS,ZB etc = Y/N):
and what is the Measure Temp (MT) and is the zone “Auto Enabled” (?):
"ZAS": {
"MT": "999",
"AE": "N"
},
I’ve got 4 heating zones and a single controller, so will never see anything useful in the “MT” field (but intend to use my Xioami sensors to provide equivalent temp measure/control). I am wondering how/if the behaviour (and messaging) is different for multi-controller setups?
. Later tonight I’ll try and convert it to an actual python_script component.
local access is broken so will need to reset the module. I’ve tried a reboot without luck, so will try leaving it off for a few minutes - if no good then I’ll do the reset and change it to ‘home direct’ mode then, as I don’t need the cloud access feature anyhow.
No doubt this is where the difference between me hacking something up that works in my case, and a somewhat-professional package (like the Touch APP) will be