Ah. So I had to select location and then the task you’ve shown. Learning where all of this stuff is found is frustrating. I thought this had to be an expression.
I am using gcal and one of the switch attributes is from the google calendar description field. In the description field I am putting a json string like {"switch": "myname", "scene": "my scene"}
When the virtual switch created by gcal turns on I am reading the description attribute to get the json string I defined in the google calendar event.
It’s not an issue with GCal. I’m just frustrated with all of the limitations our rules engine have. I get why they’re the way they are.
I’m just starting to believe I’ve outgrown Hubitat. I’m more of a tinkerer than a home automation enthusiast and starting to find Hubitat too restrictive.
I know. However with no real IDE in hubitat, I find it frustrating to have to import my code from git every time I want to test it. With openHAB I can connect vscode to a running container and develop in a running environment.
I mean if you know of a way to do this with hubitat, I am happy to entertain it. The best option I can think of is to use the maker api and just develop all of my stuff outside of hubitat. However that means I’ll have 2 points of failure if something stops working.
Have you looked at home assistant? Seems very good if you like tinkering! I have it running in a VM just accessing network devices. There are integrations to bring your hubitat devices in to HA and HA devices back to HE. (two separate integrations)
I’m pretty sure hubitat CAN do what I’m looking for however I continue to strive to have an environment that does not require me to update a rule every time I make a change to the hardware I have. Like I said I am a tinkerer and like to buy new HA devices to try them out. For instance in Webcore I had to switch from passing a dictionary as a string to something like switchname|scenename and then just splitting it in two parts on the "|". However this seems dumb to me when I could use a dictionary as a string, covert it and just reference the key.
That being said I have these requirements:
Devices can be passed to a rule dynamically which will be used in the rule
Dictionaries must be natively supported. This means if I pass a dictionary as a string I should be able to use something similar to json.loads to convert it.
I do not want to have to escape items to make the dictionary usable by a rule.
IDE integration is a MUST
Python support would be nice, but groovy isn’t bad. Just adding this to a list of things I am using to decide where I want to land with HA.
Integration to a password manager for building out secure centralized passwords
All of these I could create on my own and would be happy to do it with hubitat if it wasn’t for lack of IDE integration.
So as you see this is more of a tinkering development need than a use case for hubitat.
I love coding but I’m also very picky on how I want to develop. LOL
As a final note. I’ve started working on my own python modules using maker api to do everything more dynamically. However I really don’t want this to be long term, as I don’t want to have another container or hub running to do automation that a single hub should be able to do.
My code is interfacing with my local password manager to pull any secrets it needs.
I have looked at home assistant. I’ve been comparing Home Assistant and openHAB to see if I may be happier on one of those.
I mean I’ve been on hubitat for quite some time and always found that it worked well, but it’s never been 100% of what I’ve been looking for. So I’ve been digging into Webcore and rule machine more and I just keep finding that there is nothing built in that makes me happy. So when I started developing in hubitat I found myself getting irritated that my own IDE wasn’t really supported for development.
Not that hubitat is horrible, I just want what it can’t offer,
I’ve used HA mainly to bring in devices that HE does not support. As far as rules engines go, I think webcore is by far the best I have come across. I move from samsung smart things to HE when they dropped WC. I’ve also made use of node red for a few use cases.
It would be nice to just have one platform, but if you want full flexibility, I think we’re some way off from that.
Thanks. I just looked into it and while it looks great I’d really like to not have to start learning a new language again. OpenHAB supports python and other shells so it makes it very easy for me to develop on.
Ive also been looking at my HA environment and like 90% of my lighting is hue. Back in the day when I started using hue the api was very basic so you couldn’t control a ton of scenes easily. Over time it’s gotten better so developing custom stuff has become easier. As zwave and zgibee switches have failed over time I’ve been replacing them with friends of hue switches.
I’ve also pretty much given up on all of my window sensors because I’m tired of replacing batteries. Seems like the battery notification in hubitat isn’t very reliable.
I’ve been running the hue contact sensors for a few months now on my doors and they seem to report well and have accurate battery notifications.
My other devices are supported by HomeKit so between HomeKit and some custom development I think I may actually be able to get off of hubitat.
So who knows, maybe I won’t bother going to openHAB. We’ll see…
Hi, Im the author of the VSCode plug-in. It's not deprecated, but I haven't had much need to change it for a while. The few people who use it, including myself seem to really like it. It's a huge timesaver. If there are improvements to be made, i am happy to consider them.