Apologies for the lack of context - I assumed this would appear as a reply to my original question about advancing a scheduled temperature change in a Wiser room from another integration.
According to the user manual the solid red light on the hub means it is either doing a firmware update or the hub has lost contact with cloud services. A disconnection from the local WiFi is indicated by a flashing red light.
Yeah that was what Iād thought initially but it would appear that the hub assumes it is connected before the entire process completes.
I.e. itās connected to the WiFi network but doesnāt have an IP - led goes solid red because itās āconnectedā even though there is no hope of actually communicating with it 
Iāve now managed to get it back on though after many many attempts to go through the WiFi setup process, the hub also crashed twice while doing thisā¦ when activating the setup mode it reset itself (all LEDs off, then the boot cycle of LEDs) eventually after about 15 attempts it managed to connect and I am not touching it 
If you want to post a link to your code that isnāt working Iām happy to have a look for you.
I finally managed to get my hands on a couple of Salus PS600 Temperature Sensors, as discussed previously on this thread. Iām having no joy getting them to work with Zigbee2MQTT though. They are listed as supported, but are showing as āNot supportedā when added:
Has anyone got these working with Zigbee2MQTT? I noticed that @Geoffw said he was using them with ZHA. Normally ZHA is behind Zigbee2MQTT with device support, so I am really surprised Iām having issues. Does anyone with in-depth Zigbee expertise have any ideas on what I can do to get them working? If not, I may have to return them. 
I am using my PS600 with ZHA and a Sonoff Zigbee 3.0 USB Dongle. One of the two devices was recognised straight away and worked without any problems. I had quite a bit of difficulty with the second device, though if I remember rightly it was more to do with the updating of temperature readings.
The device has a small mounting bracket with a hook and a magnet. Where the hook fits into the body of the device there is a very small(black) micro switch. The printed circuit board on which this micro switch was mounted was slightly loose meaning that the micros which did not always make contact.
If the switch is not closed the device appears to be alive but does not report temperature.
Might be worth putting a small folded paper on top of the switch to insure it is closed and then try reconfiguring the device.
I am sorry I am a beginner with home assistance so cannot give you any detailed advice.
I could send the diagnostic download if that would help.
Thanks @Geoffw, but unfortunately thatās not my problem. Itās that itās not being recognised by Zigbee2MQTT. Well it is, but itās saying itās not supported and itās not functional at all.
It looks like the specific model number is not recognised by the herdsman converters that z2m uses. There were some additional models added in sept (seems model number presented is very wierd). See comit below.
I suspect this model number needs adding to this list. Not sure how you get it exactly to raise an issue to have added. Seems it only supports temp reporting however and not battery level.
1 Like
Thanks @msp1974. It looks like itās a known issue with the zigbeeModel ID changing during pairing. However, I have found a solution by creating a custom external converter file, as instructed here.
Itās very hit and miss, as some IDs simply donāt seem to be recognised, even when listed in the custom converter. See here for the issue and my custom converter.
Yes, itās only temperature, link quality and OTA updates. No battery level for some strange reason. At least they are recognised now and are reporting the temperature. I just hope I never need to re-pair them!
Battery level always shows as unknown but it has an attribute battery voltage which seam to report a realistic value. it also has attributes for type and number just in case someone inserts an extra battery when you not looking. Mine looks like this on the diagnostic download.
"manufacturer": "Computime",
"model": "SS909ZB",
"name": "Computime SS909ZB",
"quirk_applied": false,
"quirk_class": "zigpy.device.Device",
"manufacturer_code": 4216,Unfortunately, those battery attributes are not available in Zigbee2MQTT. Hopefully someone will fix this properly at some point. I suspect it could be a while though, as this is quite a niche product.
I have the temperatures being reported now. Thatās the main thing. I just need to mount the sensors on the flow and return pipes of my boiler now. 
A cable tie with a bit of pipe insulation over the top makes a quick and dirty solution if you not measuring a 15 pipe.
@msp1974, you can find the code for at https://github.com/TimClement/heating_automation. Itās very much a work in progress. The critical call is in sensor.py, around line 160 - I have included the two versions that didnāt work as commented lines along with the event version, which does work in conjunction with an automation. Thanks for taking a look at this.
Link to github repo doesnāt work.
@msp1974: sorry, Iām on a learning curve for almost everything involved in this. Repo was marked private. Now public, which I assume will help. The link seems to be valid as a link.
I think (as you suspected) this is an async issue. You are trying to call an async function without await from a non async function. Try hass.services.call instead.
So @tombadog and @robertwigley, I have continued to think if passive mode following the schedule can be done and makes sense.
Below is what I have come up with. Instead of the swicth to turn on/off passive mode, there is now a selector to set it to disabled, manual or follow schedule.
Disabled is obviously off
Manual is as before, setting the min/max temp range (also allows boost)
Follow Schedule will allow manual setting of the min temp but prevent changing the max temp (see bug issue below) and instead this will always be current schedule temp (also allows boost)
So questions (for all on this forum):
- Does this make sense?
- Is it what you had in mind?
- Is this better being able to set passive mode type by room rather than as a whole?
Thermostat Card Bug
Whilst doing this, I have discovered a bug in the thermostat card in that it does not update if you set the temp by the card but the temp does not actually update. It remains on the temp you tried to set instead of reverting to the actual set temp. You will see in the video above that I refresh the page to display the max temp back to schedule. This has been raised with HA frontend repo but is a bit of a problem for the follow schedule passive mode.
4 Likes
From my perspective, this looks great and even better than I imagined. I would be delighted if this could be added to the integration in this form but of course only if others agree with this.
Been bashing my head against boosting / cancelling this afternoon, this will be down to me missing something. The integration dropped in wonderfully smoothly this morning.
This is the code from way back up the thread, boosting working exactly as expected. Cancelling however is an entirely other matter. Iāve had a nose around in the code and the it looks like itās looking for a null match rather than āCancel Boostā.
The question for all you wonderful people is what blindingly obvious and stupid error have I made 
- type: button
tap_action:
action: call-service
service: climate.set_preset_mode
service_data:
preset_mode: Boost 2h
target:
entity_id: climate.wiser_study_birds
entity: climate.wiser_study_birds
icon: mdi:fire
name: 2h
- type: button
tap_action:
action: call-service
service: climate.set_preset_mode
service_data:
preset_mode: Cancel Boost
target:
entity_id: climate.wiser_study_birds
entity: climate.wiser_study_birds
icon: mdi:fire
name: Cancel
climate.py
elif WISER_PRESETS[preset_mode] == 0:
await self._room.cancel_overrides()
It changed some time ago (burried somewhere above! and instead of cancel boost you should use cancel overrides. If you have a thermostat card, click the more info 3 dots and you will see the available preset modes listed there.
WISER_PRESETS = {"Advance Schedule": 0, "Cancel Overrides": 0}
Hope that helps.