Yes, for me too, this fixes it.
- service: light.toggle
data: {}
target:
entity_id: light.window_lamp
identical issue
1 Like
Not going to lie, I’m very surprised in how coincidental this pinged up with the same issue at the same time yet my understanding is that device actions probably hasn’t worked at all ever in this integration (although it could’ve been a recent update that changed somehing but I’ve never used device actions and haven’t had anyone raising issues with the device action for reference).
But I am more surprised (and partially disturbed) that users resort to device action instead of service call or doesn’t try service call when that has been the stardard since HA was introduced. Using device actions can be a nightmare to maintain or update when a simple device has been switched with the same type or even something completely different whereas entity_id’s are always manageable and flexible.
Coincidences happen. Weird but true.
I only discovered your work today, so HA update not relevant to me.
I use device actions all the time as so many others, they work and they are easy, it doesn’t disturb me. They rely on unique IDs, no problem there. Why would they exist if we were not meant to use them? They are not deprecated or unsupported. The integration should either support them or document that it doesn’t support them or even not allow them.
Not to take anything away from the end result, it’s a great integration that you’ve created.
1 Like
Indeed they do but there’s no harm in pointing it out to give awareness and context to the rarity of the issue. It’s also funny how I mention that if there’s another person with the same issue and I can find a pattern 
.
It’s always relevant, this could’ve worked fine previously but no one has raised it yet because it’s fresh and new to a recent update.
Entity id’s are also unique id’s… put it this way, if you simply just change a bulb for eg. Hue from one room to another or you just bought a new one to replace an old one, then you need to update all your automations and scripts to reflect that. These id’s are generated by HA in the background and is also reliant/bind on how an integration detemines it’s uniqueness (serial, mac etc.). If you remove an integration because it’s playing up then re-add said integration then you are prone to those same devices having completely different device id’s which again results in having to change all automations and scripts. (this is dependant on the integration/component)
Yet on the other hand if you swap a device for eg. a light, then you only need to change the entity id and viola, everything within Home Assistant works with that device as it should, even if the device is a completely different brand etc.
The introduction of Device action is simply a hand holding mechanism to help less tech savy people to interact with the devices. Unfortunatelly this came with caveats that probably wasn’t initially seen when introduced.
While i’m not “against” the action, I don’t encourage people to use it and as this is relevant to this integration, I feel my perspective on it is warranted.
1 Like
I’m tech savy, I use them because they are easy since they were introduced, been using HA for many years. The techy savy Statement is an opinion not a fact.
It’s of course your choice not to support them so please document that it doesn’t support them and why.
Introducing something for it’s intended purpose doesn’t mean a person outside that scope can’t or shouldn’t use it. Even the statement “they are easy” just emphasises the point lol.
I never said it wont support it or don’t, the source is chained down to HA’s core to handle the execution.
I must admit that I always try Device Action first and Service Call second because it just feels more intuitive to me. Service Calls are what I use for things that don’t work with Device Actions directly.
Maybe I should reconsider that…
1 Like
Intuitive! That’s exactly it. You do what’s intuitive, that’s how users work regardless of their technical level.
1 Like
Which also generally can come with trade-offs. Also on it’s face value it’s intuitive, but it’s not when it comes to the scenarios like mention above which then turns it into a chore.
Again if you’re happy using it then by all means use it, but I’m still putting my 2 cents in for what it’s worth
I can’t imagine why anyone ever would want to specify anything in a format that isn’t text. If your server crashes, don’t you need to reprogram everything? Even if you have a backup, what do you do when you have another physical location where you want to do the same?
I think the summary for this project is linguistically awful, but if it helps other people, great.
If there is an API to use this thing, perhaps I might care about it, if it’s documented.
Where would the data come from on a reboot etc? It’s stored no differently to how everything else in HA is stored. I think you took a wild shot in the dark here
By crash, I mean “if its molecules die due to entropy”. Wasn’t that obvious?
Oh of course it was but i guess stupid questions comes with stupid answers 
1 Like
If you think it is stupid to be able to quickly deploy the exact same solution with for example a cold standby, you are the one that is stupid.
I didn’t think anything of the sort, you did, in fact it didn’t even cross my mind, probably because it’s your fantasised uneducated/untested assumption
So, you are saying questions are stupid, because you are ignorant and lack imagination? OK.
Sure, roll with that 
. I also didn’t ignore so that counters the ignorant claim
You literally don’t know what ignorant means.
lacking knowledge or awareness in general; uneducated.
Like I said, I didn’t ignore hence I was aware of your comment, gave my “educated” response “It’s stored no differently to how everything else in HA is stored.”… Not sure what’s tripping you up.
It’s also ironic calling someone ignorant when you’re the one who chose not to educate yourself on the integration and went with pure assumptions
1 Like