Thanks to @Dustyd5 the Fob driver has been extensively updated, part of which adds support for the Care Pendant in "fob mode".
The Pendant can now be used as a one-button device with presence (the firmware sends identical messages for both buttons, so they cannot be differentiated).
Overall the driver is more robust and reliable, now using the hub's library code features to avoid duplication of effort. As I'm still using these devices every day I'll be updating all of the drivers in the coming weeks.
This is wonderful news... I can't wait to try it.
It will have to wait a bit though as I'm working away from home for several months and won't get back to my system for a while. Dang!
Updated the SmartPlug driver to use the new libraries, and updated the libraries to support the SmartPlugs. They will now generate about half the number of events, reducing load on the hub.
Thanks to @iris figuring out the correct way to send commands to the attribute cluster, I've also been able to add proper user feedback for the Iris Care Pendant.
I was going to roll this into the Fob driver, but it's actually far more useful with its own.
The Pendant is essentially a Fob running specialised firmware. It can be used as a one-button Fob by reassigning the Fob driver, or it can be used in the manner of a critical care pendant.
Pressing either button registers a Push event and sets the device into "Help Needed" mode, signified by a single beep and single red flash. The Pendant stays in this mode, repeating the call every 30 seconds until the hub acknowledges the request, at which point it switches to "Help Called" mode, beeping twice and flashing the LEDs red continuously. This mode cannot be exited from the Pendant.
The Push events from the "Help Needed" mode should be used to trigger some form of assistance. Once that assistance is confirmed the Pendant can be switched "on", which triggers "Help Coming" mode. This is indicated to the user by three beeps and the LEDs flashing green continuously.
The Pendant can be set back to "Idle" mode by being switched "off".
NOTE: Though you could use this driver to create a facsimile of a critical care pendant system, absolutely no guarantee of reliability or suitability is given or implied.
BTW, if anybody can work out how you get the tones to play on a standard AlertMe Fob, I'd love to know. They used to play an acknowledgement tri-tone, triggered by the original hub once the "home" or "away" mode was successfully requested.
Unlike the Pendant, there's no 00C0 attribute cluster. The Pendant has 00F0 and 00C0 inClusters, while the Fob has 00F0, 00F3, 00F4 and 00F1. Trigger events come in on 00F3, I've never seen anything from 00F4. Device status information comes in on 00F0, but is requested on 00F6. Yes, 6.
Updated recently, ditching the "proprietary" batteryVoltage attribute for the supported voltage attribute. This would normally be used for mains voltage monitoring, but seeing as none of this gear does such a thing it makes more sense to use this existing attribute for the battery instead.
This also makes logging out through influxdb-logger possible without messing with the code for that, and probably also enables some built-in automation triggers that were not previously possible.
I'll be doing this for my other drivers as time allows.
Hi there! I was away from my system for the last 8 months and unable to try this until now. My attempt to import the code from GitHub resulted in "unexpected char: '#' @ line 11, column 1."
I don't know what HPM is... probably because I have not updated the hub in... um... years. Do I need to have more current hub firmware running for this to work?
Hello! So, you'll need at least version 2.2.8 for the drivers to work - I think that was when code libraries were introduced. It's a way of keeping common code in one place to simplify development and (hopefully!) minimise bugs and duplication.
If you fire up your hub and see "Libraries code" under the Developer tools on the left, you're good to go!
If not then yes, you'll need to update your hub. However, there have been some issues with the latest 2.3.4 release and I'm still running 2.3.3.140, which I don't believe is available to download. It may be worth sitting it out for a little until the dust settles on the latest release if you do need to upgrade.
Whatever version you're running I'd really recommend installing Hubitat Package Manager (HPM). It makes installing and keeping community code up-to-date much easier. If you don't want to do that then I can let you know how to install manually... if I haven't already put that in the first post, I really should do!
Yes, that'll get you - no libraries, no dice I'm afraid!
I don't think it's everyone, I think there would be more noise if it were. It seems hit-and-miss and not necessarily related to the HomeKit feature. People who aren't using it are getting issues and those who aren't using it are.
Seems version 2.3.4.150 and later are getting better responses from people, but I'm just waiting it out.
Man, I just read that entire thread from your initial post in November. Grueling!
What confuses me is this whole notion of rebooting all the time.
I never re-boot my thang. But it sounds like it's been something other people do a lot, even before this performance debacle. Do you think I'm I just lucky or is my version so old it just doesn't need that kind of maintenance?
Or maybe it's just something that the uber-nerds do for fun?
I think I've only needed to force a reboot once or twice, but I've never had it automated. It's always been a situation where I've needed to pull the power out of the back! At least one of those occasions was my own fault.
Just updated the SmartPlug driver to better recover from mains supply failures when the battery is either duff or the device has been off grid power for long enough for the battery to deplete.
I've been adding some more SPG100 and "SPG900" plugs recently and a couple have had expired batteries. When the mains supply fails they would manage to send out their last "no power!" panic message before dying. When the supply came back they'd pop back to life but the power control message was received too soon, so when startup was properly completed they would fall back to local-only control until their next ranging report was requested (every 6 hours).
When power is restored the plug will now become remote-controllable again after twenty seconds. The indicator LED will light briefly when the power comes back, go off as the startup is completed and then should light back up again within twenty seconds when everything has stabilised.
In any condition the plug should always return to its pre-shutdown relay state (so if it was on when the power failed, it will turn back on when the power is restored). All of this only applies if the battery does not keep the plug running while the power is off. In the event of a short-term mains disconnection the plug will stay controllable and continue to act as a repeater.
Hi. I've recently bought a C7. Have added HPM and loaded the library (which shows as 2 libraries). I can get various sensors to connect and assign the correct Alertme driver but they don't seem to read the states correctly. I have a lamp but this stays flashing (blue) even though I can see it has connect. I am unable to control it in any way. Any suggestions as what I am doing wrong? Thanks
These drivers now support the healthStatus custom attribute, so will no longer misuse presence as a means of reporting connectivity to your MQTT broker.
I'm sorry I hadn't spotted this until now. They should work fine on your C7, could you try updating to the latest driver version and hitting "Configure" on the device page?
There've been a fair few changes to the drivers to make them more robust in the past few months, but really they should have worked fine straight away unless there are any hardware issues with your devices.
Good Day Sir, I have acquired the Iris care pendant V2.. I guess. It's the small round one with only the red cross button in front. It joined with 2 endpoints but it not functioning, that's neither endpoint with your driver or the driver from @iris (even tho I know his was intended for the V1 version that looks like a small blunt)
Is it trivial to correct the driver to have this working?
Here's some logs after pairing both endpoints:
Summary
dev:7682023-09-13 07:21:28.065 PMinfoHue Motion Kitchen illuminance is 0 Lux
dev:18792023-09-13 07:20:51.058 PMinfoMotion Hue 3D printer illuminance is 0 Lux
dev:20522023-09-13 07:20:43.003 PMinfoApplication ID Received
Ooh, not really, unless I have one here with me. Even then it may not be trivial.
I'd need to see all of the button press combinations and the messages it sends, plus what it does when it receives commands. The pendants (at the least the V1 type, I didn't know there was a V2) have to be told to leave their alert mode and return to normal operation, and I have no way of knowing which messages it needs to receive.
