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.
Thanks for your efforts in getting old AlertMe devices supported. I've just got a C-7 hub and so far it has paired with an AlertMe SPG100 and the AlertMe Key Fob. My next job is to change the batteries in 27 other SPG100 and get them paired. It's great to see this old gear come back to life!
Ah, amazing! I love hearing about these devices getting use. Of all my AlertMe gear I’ve only ever had one motion sensor fail on me in nearly fifteen years, and nobody out there makes SmartPlugs as good.
Yes AlertMe produced some excellent gear for a startup company. It was a sad day when the people who bought the company switched off the AlertMe server, but it taught me a valuable lesson, do not trust cloud based technology.
I'm still adding all my old SPG100. 18 on the network now and 10 more to go.
I have a query about what to do following internal battery replacement. Most units come up saying Battery Level 0% on the Devices page and have log entries like this: " dev:792024-10-25 11:54:55.835 AMwarnDesk Lamp - SPG100 12 : Battery : 0% (4.025 V) dev:792024-10-25 11:54:55.834 AMwarnDesk Lamp - SPG100 12 : Battery : Exhausted battery requires replacement."
Is there a way to force it to new battery status? The battery voltages certainly look ok but are marked as 0%.
That's interesting, all of mine hover around 4.2 V, but this is while there's mains present and so the charge circuit is running. Leave them to charge a few days and let me know where they get to - and if you're really keen, once they're charged, kill the power to some and see what the voltage drops to without mains input. And for extra credit, see what voltage they discharge to before powering off!
I'm happy to update the driver to better calculate the percentages, as it doesn't take into account on-charge and off-charge voltages. But it could.
OK I will keep a close eye on them all. I bought the replacement batteries from
jjbatteryshop2010 on Ebay and I suspect they are new old stock. I got all they had and they were actually intended for Motorola MBP31 Baby Monitor. I had to swap the connector housing for the ones on the old batteries, luckily the crimp connectors are the same type. The voltages on some SPG100 are creeping up by mV so I think the trickle charge current must be quite small.
Added a basic "Disable Off" preference to the SmartPlug driver in v1.56.
I'd moved a SmartPlug to monitor the power usage of our fridge, then spotted it had been part of my "nightly reset" task which would have turned it off while I was asleep. Glad I caught it, but could have been a silly mistake.
This little toggle in the Preferences will completely disable sending the Off command to a SmartPlug and just log an "Off is disabled" warning instead.
Just a little note for folks using the Smart Plugs, I've found that a few of mine occasionally enter a "panic" state where they rapidly double-flash their LED. They remain controllable, but report nothing back to the hub whatsoever, so get marked as offline.
I've spent a little time this evening trying to fix this remotely, but nothing I've attempted works. I'm inclined to believe these plugs may be developing a hardware fault, as the three (out of more than twenty) which display this issue are on two different firmware versions, and those versions are in use on other plugs which have never exhibited this issue. They're also plugs in favourable locations, so it's unlikely to be a signal loss problem. I have some at the end of the garden which are faultless.
It's possible to get such plugs into a state where it looks like they're working by putting the hub into pairing mode, but this just gives a false positive. For some time the plug will show a solid LED again once reconfigured, but will not send reports or state changes.
The only way to bring them back to life is a physical reboot by holding the power button down for ten seconds. The driver will reconfigure them on startup without requiring re-pairing. They may then work again for days, weeks, or even months.
Recent platform updates have had me tinkering again, so if you're using these drivers, particularly with the SmartPlugs, I'd recommend updating.
I've wandered through the code and optimised when we fire events, in order to reduce database writes and to drop hub load. Essentially the driver now implements more checks against current values, only firing an event if values have really changed.
Those SmartPlugs are very chatty, and as these are only supported on C7 hubs and below any saving in processing power is a good thing in my book.
