I too have started using Chrome on Mac as the UI is Safari is sub-optimal. Most issues with Safari UI seems to still center around two main themes and I apologize for the lack of specifics:
Safari seems to cache the hubitat hub frequently. For example, if you create a new rule using RM and hit āDoneā the rule will not appear in Safari, however the rule appears in Chrome or will appear in Safari if you clear the cache which is less than convenient; and
When using apps that require a start end time (ie. turn on the light at 7:00 a.m.), setting the time in Safari usually does not work meaning you can select 7:00 a.m. but the time will not input leaving the user unable to finalize the rule/trigger/condition.
These are just a few of the Safari issues, but by no means a deal breaker as Chrome has no issues. Of course, it makes it a bit more difficult to use hubitat on an iPad.
Does the hue integration work with the dashboard? As I am playing around with the dashboard and lights from Sengled work when I click the on/off icon but none of the hue lights do.
I can see the actions coming through on the Device Events tab but nothing is happening. When I give the voice command no action is recorded there however.
Yeah so it's not a problem with the dashboard as I can turn on and off the sengled lights via the admin UI but no go for the Hue lights. The event fires in the events list but just no change in the light.
On the device page for the bridge it says " * status : Offline" but it is on and working as works fine with the Hue app.
If an ip address change was the problem, you should setup a dhcp reservation for your hue hub on your router. Otherwise this will happen again the next time your hub gets a new IP address.
I guess it is because yesterday I changed name for one of my bulbs and refreshed through Hue app for the name change on the device list.. before that, I have never seen this issue..
Sorry to bump an old thread but has there been any update in the last 4 months on this?
I'm considering a move from ST but I currently use ST and Hue B Smart to drive most of my lighting automation through Hue bridge scenes as I can set transition times and get uniformity across bulbs, even across rooms. So this is a pretty important platform feature to me; a show stopper on migrating platforms. I don't care to create/modify Hue scenes but at least need to be able to invoke them.
I have near a dozen Android apps that are able to read/modify and use the bridge scenes (several free) so seems like this should not be a huge endeavor. The docs only indicate support for groups.
I haven't used it since the stock integration does almost everything I want--but like you, I'd also like access to Hue scenes. I don't want to risk running custom code over that, but from that thread, it looks like most people have had good experiences. I'd almost like a stripped down version that just did scenes (or maybe I could do that myself?), but I'm making due with Hubitat scenes and Hue-paired devices with Hue scenes for now (plus automation that usually means I don't need to worry about any of this at all).
Hey thanks for the timely info! I ran a few google and forum searches and didn't catch that port and it's really good to know it's out there. I read through it; seemingly workable. Looks like there's a ported Home Assistant MQTT broker too. About to build up a Pi for it and trying to figure out what comes next and if ST will be part of it.
I'm really amazed how crude all this home automation stuff still is. Joe consumer is way over their head much beyond Alexa turn on the light. I'm waiting (well dreaming) for a system with polished web and mobile interfaces and a Node Red like rule experience. Built with non-ported-hack-to-begin-with drivers and all with an internal radios and no fricken dongles making them awkward to mount and subject to whims of felines looking to bring down the house. My DIY rate ~5-10 years, industry like 10-20+. I'll be handing this project (and my house) down to my son lol.
Sort of--there's an "MQTT Bridge" Hubitat app (also a port of the ST original), which also requires an MQTT bridge application ("real"/node.js app) running on a server, in addition to the actual MQTT broker (which you can run on the same server, a different server, or use the one built in to Home Assistant if that works for you). But the Hubitat app itself is not a broker. There's also nothing Home-Assistantāspecific about it, though that does seem to be a common use case since Home Assistant has built-in MQTT publishing and subscription capabilities.
If internal radios are important to you, rumor (and CES photos) has it that the next revision of the Hubitat hub will have them, though no significant spec changes are expected.
Stringify is probably close to what you're asking for, though it's cloud-dependent. There are also other "easy" things like IFTTT and Alexa routines that probably have a similar goal but really only allow fairly simple automations and, of course, are also cloud-dependent. A common saying is that in software UIs, there is a tradeoff between power and ease of use, so on the "powerful" side we've got things like webCoRE and Rule Machine, and on the "easy" side we get things like IFTTT. (For some reason, in the smart home field, there also tends to be a dichotomy between "local and simple" vs "cloud-based and powerful," even when "cloud power" is by no means needed. That's one of my favorite things about Hubitat: custom code, as powerful as you want it to be, runs locally.) NodeRed looks neat and I've seen screenshots but never tried in person. It seems to be a good compromise. I have tried PLEG on Vera, which I was told was also supposed to be a good compromise between these two (a suggested alternative to webCoRE for ST ex-pats like me), but I was not able to make anything useful out of it.
