I seem to be having a problem with the switchbot lock as of today.. maybe started yesterday. It's no longer able to unlock or lock through hubitat. Works fine through the switchbot app.. Here is the debug log I spotted (the not supported device type caught my eye):
They never officially supported this, so I'm guessing they either changed or just turned it off. I'll keep an eye on the chatter to see if anyone figures it out.
The perils of relying on a proprietary cloud API...
Been using your curtain driver for a while @tomw - works perfectly - thank you.
Just want to check if something is possible though, I've recently got a set of blind motors which report:
0% = Closed
100% = Open
I know this is opposite to your driver and I know you've written it to match the SwitchBot app, but is there a way to reverse the logic so my dashboard lines up? Spoken with the blind driver guy and he's just matched the default Hubitat driver logic so doesn't really want to change it.
I've tried reversing
case 95..100:
windowShade = "closed"
switchState = "off"
break
case 0..5:
windowShade = "open"
switchState = "on"
break
But then it reports open when closed (and reverse), I just want the status flipped on the dashboard.
It looks like the lock won't be supported any more for locking and unlocking commands. Should I remove it from my integration, or is reflecting its lock state still useful?
OK, I am thinking that I will just leave the driver as-is (meaning it will error out into the debug logs) in case it ever changes in the future. The alternative would be a "not supported" debug log message or status when lock() or unlock() is called. Any preference?
@tomw is it possible to change the percentage in which the dashboards reflect open and closed. No matter how much I tweak it the curtains show up as open in my dashboard. If 90-100% could be considered closed that that fix the problem.
Also, does anybody have a solution for Alexa commands. Currently telling her to open actually closes and vice versa.
I've done it in the switchbot app. It even reads 99% sometimes. Have to repeat close command a few times to get it to read closed. Hubitat is almost impossible. Even if it shows closed a few minutes later it shows open again. The closed stat is so very narrow.
Cool, I can go with 10% on either end instead of 5% if you think that would help. The original numbers were basically arbitrary in the first place.
Suggestion: make that edit in your local copy and let it run for a couple days to make sure it works the way you want. If so, I'll just make that change in my next release.
On this topic of positions of the curtains. I actually made virtual dimmer switches for all my curtains then use those to set their positions with a webcore script. Basically as long as the curtains reporting value is greater then 10 or less then 10 of the virtual dimmers value they are in the right position. If the physical value (real sb curtain device) goes outside that range or if the virtual value changes the physical value is set to what the virtual dimmers value is.
I set it up this way because I had a hell of a time at the start with the curtains not always getting the api request. So this way I have a timer check after two minutes of a requested curtain change to make sure they moved. If not, it will try again.
Not sure if this will help anyone else, but just thought I'd put it out there.
@tomw I've reverted my curtain logic back to your settings. What seems to be happening is after what seems like four minutes it flips to the opposite of what it should be. I'm wondering if it's not the open/close but instead the on/off. I don't know what to think or do anymore. Don't change your driver based on what I've said earlier.
I've also noticed a lot of comm errors. It will open the curtain but than give an error saying the command didn't go through. Not sure what to think about all of this.
Using the original language in the driver I closed the curtain at 9:20. At 9:25 it just flipped it to the open position even though neither I, not the bot did anything. Is my HE haunted? Any thoughts? There were no errors on this example.
It sounds like the next polled refresh is updating the values, and there is some lag. They still don't support events on curtains, so it just periodically refreshes. The default period is 5 minutes.
If you want to speed up testing while you are looking into it, I'll bet you can get that update to happen by calling Refresh on the curtain virtual device. Just hit it a bit after they stop moving.
You mentioned that you changed the code at some point. Maybe the 9:20 events were with the driver with logic of 100=closed, then you switched the code, then when the device refreshed itself at 9:25 it was again using 100=open?
If it wasn't that, then I'm totally stumped. windowShade and switch only update when there's a value that also causes a level and position update.
I'm going to let it settle for today. I'll look at it again tomorrow night. I've reverted back to your logic before the 9:20 event. It corrected when I hit closed again. The curtains were already closed though the dashboard showed open. After hitting the close command again obviously the bots did nothing because they were already closed. It switched the dashboard to closed but reverted yet again.
Something is suddenly weird with everybody's curtains, it seems. I wonder if they're having an issue on the cloud side, or if something has changed in the device behavior between different versions or something.
I'll take a look at the issues reported against their API to see if anything seems potentially relevant. Let me know if you notice any other clues in the meantime.
Well I suspected that maybe open/on and closed/off may be the culprit so I switched to open/off and closed/on. That did NOT help. After 4-5 minutes it reverted to the wrong status again
I'll keep playing around with it when I can.
I know nothing about programming but line 81-83 seems like it would set the switch to on no matter what? Are these curtains timing out after inactivity (4-5) minutes and that is screwing with on/off, which in turn changes the position data since on=open?
You may be on to something there. Honestly, the code assumes that the curtains are going to be a lot more prompt and reliable in their reporting than they probably actually are. Your hunch that the statuses get "stuck" and catch up later is probably correct.
It may make sense to strip it way down for better reliability. That would mean losing "opening" and "closing" statuses when the curtain is moving, but I'm not sure if anyone uses that for anything useful. Thoughts?
