The device is exposed as a fan entity that supports power on/off and speed 1-100.
If you are interested, give it a try. Feel free to open an issue if you have any feature requests or bug reports. Below are the installation instructions from the readme on GitHub
Installation
Requirements
Home Assistant host that supports Bluetooth Low Energy
Tested on Raspberry Pi 4 w/ Home Assistant 0.117
HACS
Add https://github.com/AustinBrunkhorst/snooz as a custom repository.
Alternatively copy custom_components/snooz/* to custom_components/snooz in your Home Assistant configuration directory.
Put your SNOOZ device in pairing mode.
Add the “SNOOZ Noise Maker” integration. Your device should be discovered automatically.
Thanks for the lightning quick fixes! Now I just need to move my HA box closer to our master bedroom…
A couple last notes that didn’t warrant a Github issue:
This may be obvious, but the snooz has to be within range and plugged in (not necessarily on) when HA is restarted. If the snooz is unplugged and HA is restarted, HA will not re-pair the snooz when it is plugged in again - a HA restart is required.
While the snooz is on, setting the fan speed to anything less than 10 resulted in no change. The snooz only has 10 speed settings and all are currently accessible, but you may want to note this limitation or potentially adjust the fan speed ranges that correspond to the snooz settings.
While HA is paired with the snooz, the snooz app (at least on Android) cannot communicate with or detect the snooz. This may be an inherent BTLE limitation, I don’t know, but it’s probably worth mentioning in the readme.
Overall, great work! Until I discovered your component, I couldn’t figure out a good way to tie the snooz into our morning alarm. I considered using a smart plug to simply power cycle the snooz but that wasn’t a great solution, and it only worked to turn the snooz OFF, not on. Now I’m happy I can pull one more piece into Home Assistant! Thanks a ton!
Thank you for taking the time to test this, as well as provide thorough feedback.
I just pushed a new version that supports device discovery and UI based configuration. The next order of business is adding the “unavailable” state so it’s clear when a previously configured device is disconnected or out of range.
Hey everyone, I’m just diving into HA for the first time and really wanted our SNOOZ to work off a flic. So far I got the flics to work. Now I am stuck trying to get the SNOOZ to work.
I’ve gotten to what seems like the last step but cannot pair with the SNOOZ.
I made sure the SNOOZ was removed from the app on my phone and my Bluetooth was off.
I unplugged the SNOOZ for 10 seconds and plugged it back in.
I held the power button down until the lights flash.
I click Add Integration from Configuration>Integrations and type Snooz and the integration comes up (it didn’t before adding it to HACS).
A screen pops up immediately that says “Aborted” “No SNOOZ devices discovered. Make sure your device is within range and in pairing mode.” then provides the instructions for how to enter pairing mode.
I am using a Raspberry Pi 3. If anyone can help me figure this out, my baby girl will thank you!
Thanks for taking the time to post your repro steps, and sorry for the delayed response here. This integration had a few problems with stability which might explain your issue with not being able to discover a device. I recently pushed some changes that should fix these issues.
Can you try updating to the latest version in HACS and see if you are still unable to discover a device? If it continues to pop up immediately with the error “No SNOOZ devices discovered”, this might indicate a problem with the Bluetooth controller on your home assistant instance.
To troubleshoot that, please provide:
Your home assistant logs after trying to add the integration
Home assistant installation method i.e. hassos, container, etc.
Will the core component (or does the current custom component) support the ESPHome bluetooth_proxy ability? Maybe it’s built-in to the HA Bluetooth support. I know the 2022.9 bluetooth_proxy support doesn’t yet support active connections, which I assume is required to call any services for the Snooz.
I have an ESP32 that can see the Snooz but not my Pi4 on which HA is running.
My goal is to add support for the new ESPHome bluetooth proxy as soon as active connections are available. It sounds like this may be possible without any code change.
@abrunkhorst, not sure if this is the place to ask, but figured I’d try: Now that Snooz is an official Home Assistant integration, what happened to the ability to transition the device on/off? Seems like that is no longer an option, but wondering if I missed something or is it is just achieved some other way now?
The core integration didn’t get any services to start out (like snooz.turn_on or snooz.turn_off). This is a temporary thing - we excluded them to reduce the amount of code to review for the first pull request.
I plan to add turn_on and turn_off this week which might make it in one of the minor releases this month.
While you’re here: are you able to share your use case and what would be most useful for you?
The goal is to reduce the need for boilerplate automations related to scheduling. I’ve been working on integrating the scheduling features the SNOOZ mobile app uses for transitioning volume levels.
The transition functionality in the custom component relies on “streaming” volume levels to the device.
The scheduling done on device doesn’t require a connection once configured which I think is ideal since the transitions will execute without a connection to the home assistant host. This should be configurable from the options UI flow in the integration.
How did you make use of transitions with the custom component?
So as of now, I’m still finding reliability to be pretty iffy, and super curious if you (and others) experience this too. Every day or two the device just refuses to respond to Home Assistant commands. Sometimes restarting Home assistant helps (but not always), and most recently I had to remove the integration and re-add/re-pair it for the device to become responsive again. Not sure if there is a problem with my device, or if it is just this integration needs time to mature, but it is a bit frustrating either way.
In terms of use case, I prefer not to use the device’s built in scheduling. Instead I use an IKEA tradfri button next to my bed that I long press to launch my “sleep mode” automation (which turns out the lights, and is supposed to turn on the Snooz). This way the device is not turning on way before/after I go to bed. When it works, it is great, but as I mentioned this is not totally reliable (yet? -see first paragraph of post). So since I prefer not to use the scheduler, that is where the ability for Home Assistant to handle fading in/fading out comes in handy. Let me know if I’m going about this all wrong though!
In terms of reliability: I can also confirm that there is nothing wrong with my Bluetooth integration, as other Bluetooth devices still respond to Home Assistant commands while the Snooz does not (whenever it feels like being unreliable).
I fully agree with the idea that scheduling on device should be supported, just like the user experience prior to HA integration. My bluetooth_proxy experience hasn’t been perfect, rarely requiring either a restart of the component or the ESP32 used to connect via the BT proxy. When that happens, having the scheduling on the device has been helpful for me. However, connectivity does seem to have improved on current versions of HA (2022.11.x) and ESPHome (2022.11.x), and I’m happy with how well it works now.
Still, being able to set a weekly schedule and then not requiring connectivity for that baseline level of performance to work is very nice. Without knowing anything about how it would be built, maybe it would be possible for the user to specify the behavior during the configuration flow?
Cold start connections can sometimes take 25 seconds to complete for me with the SNOOZ ~35 ft from the bluetooth controller. This is not ideal for on-demand scenarios like you described which is in response to the button event. I have a fixed schedule that turns my SNOOZ on/off so the long delay for cold start isn’t noticeable since I’m never waiting for it to turn on/off in response to an action.
A few troubleshooting questions:
How far is your SNOOZ from your hardware running home assistant?
Is there anything that could be adding signal interference between the hardware and SNOOZ?
If you enable debug logging for pysnooz in your configuration.yaml then filter your logs with the search query “pysnooz”, it will give us some more details to see where the time is going and bluetooth errors you’re encountering.
The integration makes an exhaustive effort to maintain a connection by auto reconnecting on disconnection, but in testing this just doesn’t hold up when the device is too far or has too much interference. Older SNOOZ hardware uses a bluetooth chip that is less reliable and exacerbates this issue (I’ve tested on the older and newer hardware).
There are a few things you can try in to mitigate some of these pain paints you described:
If logs indicate your SNOOZ can hold a connection for more than a few minutes, it might be worth scheduling a command like fan.turn_off close to when you usually activate your long press nighttime activity. This will “preload” the connection so that by the time your activity runs it won’t have a cold start.
If your home assistant hardware is physically constrained from being closer to the SNOOZ, you might consider picking up an ESP32 and running a bluetooth proxy as close to the SNOOZ as possible. This may improve connection persistence and stability.
I’ve been told WIFI capabilities are on the horizon (no ETA or details available) and I plan to add support if it becomes available. This would likely eliminate the range issues many people including myself have experienced without the need for a bluetooth proxy.
Just a quick follow-up to let you know (and confirm) that after relocating the Snooz and Bluetooth dongle to be in closer proximity to each other, the Snooz seems to be responding more reliably to commands from Home Assistant. Thanks again!
Is it possible to control the nightlight with this integration? I don’t see that feature mentioned in many places, but I know it is something that the app can control.
