So… I may have gotten the concept of neoAir wrong in the driver. I thought it was purely a temperature sensor and not a full thermostat, so that’s why there are no other fields in that device type.
So my question for you is: functionally, does a neoAir (wireless) have all the same capability as a neoStat (wired)? If so, I probably just need to change the device profile in the driver so you get a device just like the neoStat. Then you’d be able to set your profile.
If you cross reference with neoAir screen in my post above they’re the same.
Profiles allow you to choose from 2 modes, ‘timer’ or ‘thermostat’ for both stats. Timer is the traditional clock where you can set call for heat based on time. And thermostat is as you expect, temperature sensor which will call for heat if it’s drops below a specific threshold.
This update corrects a problem where all neoAir devices were treated as sensor-only devices, instead of correctly distinguishing between thermostats and sensor-only devices. (Thanks to @F_M for reporting this)
If you already have a neoAir Sensor device created, you are going to need to delete it and have it recreated with this new driver, as it will become non-functional with this driver update. (@skinnypope) My apologies for the inconvenience. (To get a device recreated after deleting it, simply do a swipe-down gesture on the neoHub device Controls screen).
If you have a neoAir device with just temperature showing, but it should be a full thermostat, once you have this driver update, you can delete it and have it recreated with the neoHub device swipe-down gesture.
Thank you for your continued development Tod, it really is much appreciated
Just to note, and this may well be just my particular system and network
every once and a while my Neostat hub locks up, this seems to affect the Heatmiser app by way of the Neostat app refusing to open and the ST integration stop working, my fix is to unplug the Neostat Hub briefly and then plug back in, this seems to reboot the Heatmiser Neohub and all is well again
Thought i might document it here incase others find similar, as i mention though, could well be just my particular install and network
Thank you @TAustin ! Working nicely (followed your instructions to delete neoHub in Smartthings app and rescan).
What does “Play a favourite” in the THEN device condition mean? Do I need to enter the name of a profile?
Edit. Your excellent README answers my question:
For selecting a Profile, use the “Play a favorite” option in Routine config screens, or the mediaPresets capability in Rules. For the value to set, use the numeric heatmiser PROFILE_ID, which will be displayed in the Info table ‘ACTIVE_PROFILE’ element. Do not use the Profile name.
I was referring to the SmartThings device Settings screen for the particular neoStat device. There is an option there that also needs to be enabled if it is being used as a timer.
As I have been using this driver more and more I have found a recurring issue where the Hub seems to lose contact with the NeoStats in the middle of the night (usually around 1-2am).
The “Status” window on the NeoSat screen shows e.g. “Updated: Tue 01:29:28”, despite it being e.g. 09:30 here in the UK right now. The routines I have then don’t work, although I only know this as the heating isn’t on (the room is cold!) or if I click into the NeoStat tile to see the Status.
I’ll try to leave logs running overnight for a while to see if I catch it happening, all I see now is an error when checking last pings:
2024-02-06T09:13:38.331906692+00:00 DEBUG heatmiser v0.3Beta Checking last pings...
2024-02-06T09:13:38.342628359+00:00 ERROR heatmiser v0.3Beta driver thread encountered error: [string "init.lua"]:388: attempt to perform arithmetic on a nil value
2024-02-06T09:13:42.363480692+00:00 DEBUG heatmiser v0.3Beta Heatmiser neoHub: Time since last refresh=60.164000034332
2024-02-06T09:13:42.379028692+00:00 DEBUG heatmiser v0.3Beta Sending websocket message: {"message_type":"hm_get_command_queue","message":"{\"token\":\"[redacted]\",\"COMMANDS\":[{\"COMMAND\":\"{'GET_LIVE_DATA':0}\",\"COMMANDID\":81}]}"}
2024-02-06T09:13:42.457695692+00:00 INFO heatmiser v0.3Beta Message sent
2024-02-06T09:13:42.507294359+00:00 DEBUG heatmiser v0.3Beta driver device thread event handled
2024-02-06T09:13:42.522431026+00:00 DEBUG heatmiser v0.3Beta driver device thread event handled
In the logs there is not response to the message sent, and the logs stop there (until the next ping check)
The timing in the middle of the night might be a coincidence, but wondering if anyone else was seeing this i.e. is this something like the Neohub looking for a firmware update overnight?
[The only other equipment I have that schedule firmware updates are my Unifi networking gear at 03:00 and my Hue hub at midday, so can’t be that]
The fix is a hard reboot of the Neohub - not ideal! After a reboot the logs shows a message response and all is well (although I still see the error in the second line above)
Quite normal actually, the loss of connection has nothing to do with Tods driver, the issue is documented in Tods write up about the driver, it is a Heatmiser issue, Heatmisers API key vanishes from the Heatmiser app, no one one knows why and Heatmiser seem unwilling to fix the issue, once the API key vanishes from the app Tods driver looses connection to the Heatmiser hub, as you found, a hard reboot restores the API key to the app and Tods driver then sees the Heatmiser hub and all is well again, it is a common issue with Heatmiser hubs
I know of other Heatmiser users that do not use ST or any 3rd party connection to Heatmiser and all say the same, the Heatmiser hub does require hard reboots quite often
Heatmiser dont include a soft reset in the app so we all have to hard boot, it is a nuisance for sure
Another annoyance, no official Heatmiser forum, if there was im pretty sure we would know how many users are affected by these somewhat hidden and down played issues
From Tods readme file
Known issues
The Token may disappear from the heatmiser app after you create it; a reboot of the neoHub may fix this
A bug in the heatmiser app exists that may prevent iOS mobile devices from creating the Token
Hi Mike, thanks for that. I hadn’t seen anyone else note the token x API issue and therefore incorrectly assumed it wasn’t a widespread / common issue.
I have a Sharptools rule that notifies me if the timestamp gets stale, so I’ll just put the hub on a smartplug and get the rule to power cycle the hub when it happens.
Definitely feels like using a sledgehammer to crack a nut!
I agree, hard booting is a terible resolution, i had the same thought as you, stick a smart plug on it and reboot remotely but it just dosent feel right like that, in fairness yanking the power socket from the rear of the hub is the same deal … i duno, maybe just my old fashioned attitude towards electronics, just dont seem right with a smart plug
Hi All, I don’t know if this is relevant to this integration effort by Tod Austin, but I have been contacted by the new Head of Product at Heatmiser today and asked if I would like to participate in beta testing of SmartThings integration? Evidently he found my details on the Heatmiser Customer Contact Portal where I upvoted Smartthings Integration along with a number of other Smartthings users. I also suggested that it might be helpful if he, or one of the developers, join the Smartthings Community Forum to ask other Heatmiser users on here.
Fozzie
Would be good for them to participate, it cant hurt there advertising if they throw an offical Works with Smartthings in there PR if they ever get round to fixing there frequent disconection issues
I upvoted that years ago when the tag was under consideration, it then changed to the current not planned tag you will find posts also get deleted
If Heatmiser are serious about the integration they may as well contact @TAustin , the work is done and apart from some ST UX limitations there is little room for improvement except the inclusion of a company name on the device page which we all know ST have not provisioned for