Can be as quick as 4-6 seconds for me. Normally within 10 seconds.
Now that you folks have had the device awhile are you finding the data is still reliable? Presence sleep snoring etc?
Snoring is hard for me to tell because neither me or my wife snore much unless we're sick.
The presence is pretty spot on. The one "gotcha" is, we have a king size bed. The sensor doesn't go all the way to the middle. So if you roll too far to the middle of the bed at night it will think you got out. I shoved the sensor a little further under the bed and it's been good so far. Of course there are other reasons why someone might not be on their side of the bed and then that throws it off 
The heart rate has been damn accurate at least compared to my Apple Watch. I'm shocked how accurate it is!
Sleep time is pretty accurate. Of course it's hard for me to say "what time did I really fall asleep?" but I can at least say when I know I'm up watching TV I've never had it say I was asleep.
So in general, super accurate. For me though the most important part was the presence which is very accurate and very fast. I'm happy with the purchase.
Data is good. The only issue I have is the Withings API requires a response from the hub within 2 seconds (same with their IFTTT integration) and the reality is that this doesn't always happen for me (probably mostly due to my poor hub performance at times but also maybe because I'm in Asia and I suspect their server is in the USA). Anyway, whatever the reason, I'm getting regular timeout errors and then corresponding emails from Withings. I've contacted their support desk and as is usual for modern organisations, got a standard reply and then nothing. Time to find the email address of their CEO I think, for a robust escalation (a favourite pastime of mine for unresponsive, irritating support desks).
That's actually really surprising. The code, literally does nothing when it receives a request (I fire it off to run in the background), so it should be near instantaneous. I did it this way so we'd be good with the 2 second limit. Yeah it sounds like something is up with your hub/internet 
Yes it's not related to your app. I get the same issue with IFTTT. It's my hub's performance from time to time and the Internet connection into Thailand I believe (it often takes time for the great smiling Thai firewall to register whatever it has to).
I think you may be overthinking this a little. I think there would be more users that would make use of an on/off switch based on in/out of bed. Anybody who has been using one of these sensors to trigger an automation have done it through ifttt which manipulates a virtual switch, so we're all used to the on/off logic related to the sleep sensor already. The case of "I flipped it to off because a guest was sleeping in my bed while I was away and didn't want it to contribute to my sleep data but it didn't really turn off" might be a once in a lifetime occurrence for 1 of thousands of users.
If you reread the posts you'll see I misunderstood what he was asking for and said I'd add it. I just said I haven't had time to get to it yet so he went ahead and did it himself for the time being. Having it turn a switch on/off is fine by me, however, I don't plan to add the Switch capability to the sleep sensor itself since it's not a Switch.
1 Like
While not entirely an HE issue, more and more people are moving away from RM to do their automations and using things such as node red. And having the sleep device as a presence sensor means we're now using home/away logic. But if I'm out of bed that doesn't mean I'm away.
To me, anything that is not present means it is not home. I think this would also create confusion for some users "My sleep sensor is showing that it's not present but it's here, I can see it under my bed. Why is it showing it's not here??" Actually this will probably happen more than the one time somebody has somebody sleeping in their bed while they're way and not wanting it to track on their sleep stats.... We can work around that by creating an automation to trigger a virtual switch that we create to give on/off logic. You could even build in that automation to the app, but I'm already doing that in IFTTT...
I would actually argue that the sleep sensor is indeed a switch. The sleep sensor is a pressure sensor not a presence detection device. Pressure sensors trigger by putting pressure ON them or taking pressure OFF of them. Presence triggers on proximity. Entering a geofence, a fob coming into range, bluetooth connecting. If it used BLE or similar to somehow detect when I'm in bed, then sure I'd agree it's a presence device. But that's not how it works. Sure, if I'm laying in my bed it means I'm home so I guess in that sense it's a presence detection device. But if I'm out of bed it doesn't mean I left the house.
I understand your thinking behind it. Someone is "present" in the bed. But that can ultimately be flawed as well. If I put a load of laundry on the bed on top of the sleep sensor it will show that someone is present in bed. But again, to me it's more logical that the sensor turned on because of the weight of the laundry, not that somebody is present in my bed because of the weight of the laundry.
I've never seen another pressure sensor integrated with present/not present on any platform. They've always been on/off. Everybody currently integrating one of these through IFTTT are doing it with virtual switches which give us on/off. There's also 3 users in this thread suggesting on/off. Ultimately you're the dev of the integration and it's your choice on how to make it. And I think you're the first on any platform to integrate the sleep sensor on/off (sorry present/not present) into your integration which is great. I just don't see any advantage to using it as a presence detection device.
A switch supports commands to turn it on/off. That is HE’s definition of a switch. This device does not support that therefore it’s not a switch.
2 Likes
And a presence sensor detects home/away so it's not really a presence sensor either.
If anything it should be PressureMeasurement, but the device doesn't support the amount of pressure, only if there is pressure or isn't pressure. So that wouldn't work either.
I feel that apps should be built for the users not the finer technicalities of the documentation.
EDIT:
After all that... it's somehow showing on/off in my ned-red integration LOL
That's your belief, that is not, however, what I have observed. I have many devices that report presence which are NOT related to home/away. I have iBeacons in each room that report whether I am in a particular room. I have a sensor that reports my car is present if it is in the garage. Heck, @jchurch was telling me he has a device that reports "present" for online and "not present" for offline. A switch, using the underlying parlance is an Actuator (something you can actuate or cause to take an action). A presensesensor is a Sensor (something that senses or reports on an observation). The Withings Sleep Pad is a Sensor, not an Actuator, therefore it's not a Switch. Do I agree with you that it has something along the lines of on/off state? Yes. But HE has no such capability, so the closest thing I can do is make it a PresenceSensor.
I don't understand how having on() and off() commands that do nothing and show up in RM as a triggerable device when it isn't makes it more user friendly. That sounds like user confusion to me.
1 Like
This is exactly what I'm saying though. iBeacons work on proximity. Your sensor in your garage for your car works on proximity. A device that reports present/not present for online and offline is based on proximity to be able to get online. None of these examples work with physical interaction to the device itself. This sleep sensor does. It doesn't detect when you're near the bed, it detects when you're physically in the bed.
Like I said, I get it and I understand your logic as well. The on/off being actionable in RM could be confusing to some, just like the present/not present could be confusing to others. I think ideally having a toggle to let the user decide would be ideal. "Toggle on to have sensor report present/not present, toggle off to have sensor report on/off". That would mean 2 device handlers, but if installed through package manager that'd be pretty easy to manage.
Ultimately, once I moved it to node-red it's translating as on/off for me so it doesn't really matter to me anymore. I'm getting the logic that makes sense in my head 
Some drivers have presence relate to the device being active on the mesh. So I think it's best not to think of presence in the restricted way you are. Presence in the bed sensor in this case means the device is registering someone as present at the device. If you need a switch to be activated by that then (1) you can do what I did and in literally less than 5 minutes add the switch to the code (I explained as clearly as I could above how to do it) or (2) set up a "shadow" rule or two in RM to activate the switch when the presence on your sleep pad changes (less good because if you reconnect your driver to Withings the sleep pad device can get blown away and your rule may be left with a trigger hanging that can't be edited - so beware). This also takes about 5 minutes 
Which is for sure less than the time it took to type all your posts above 
1 Like
I could, except...
1)It would need to be modified every time there's an update == pain in the butt
2)I have moved everything off of RM at this point as the hub performs 10x better without having to process any logic in RM. Adding RM rules to adjust is counterproductive to what a lot of people are starting to do by switching to things like node-red. But like I said initially, this isn't really an HE issue.
3)Creating virtual switches doesn't really put me any further ahead than using the sleep sensor through IFTTT which is already controlling the virtual switch. There's not much benefit to having to add another app into HE and then setting up RM rules to control it... If it were fully local that's different, but it's still a cloud based integration.
I understand why present/not present. I still don't think it follows the common train of thought, and at this point there's been 3 people saying they prefer on/off and haven't seen anybody jump in saying "wow, now that it says present it's so much better than my ifttt switch I've been using". Sure we can build workarounds to it but if there's a majority that prefer it one way, why not build it that way regardless of how it fits into "documentation".
But it also doesn't matter to me now since my node-red integration is showing it as on/off, and since that's where I handle all of my automations. The hub itself can show whatever it wants since I almost never look at it anymore unless I need to troubleshoot something.
Just curious, feel free to ignore. How long did something like this take to make?
Withings has really good api documentation which made it fairly simple. With coding and testing probably 20-30 hours. That was spread over about 9 days.
Dang..well thanks
Sorry just curious, what we’re you hoping the answer was? I’d consider this to have been one of the quickest integrations I’ve built and I’ve built about 15-20
I was thinking 1hr, maybe two, lol. It’s one of those things. I did air traffic control. “Just don’t let the two dot hit each other”
