https://community.home-assistant.io/t/yaml-being-put-to-death-by-a-thousand-cuts/194883
Before this gets out of control, I donât know that ALL integrations are not allowed to generate events. What is specifically not allowed, as best as I can understand, is that entities are not allowed to generate events â which is specifically what I was trying to do with the new UPB integration.
Also, if I understand correctly events can be generated from an integration if the event is not associated with an entity, i.e.: the event can be associated with the device. Actually, I hope this statement is true. Iâm about to submit a PR coded this way.
If you are being stupid then so am I.
Iâve read this thread twice and am still no closer.
Iâm âASSumingâ here that device triggers expose additional attributes to the AE whereby it populates options for sub entities to be picked from. ???
This in itself seems âno biggieâ and pretty much an essential step in getting the AE to generate code that has a half decent chance of working
Other than hanging all this off some long and pretty much meaningless number the âelementsâ seem fairly standard although not in a human logical sequence (being alphabetical instead).
But I have no common reference to most of this code and cannot parse it âas isâ
So like @Burningstone above (and others too) I think I shall limit my assistance to : -
- Threads that interest me
- Code I can âde-obfuscateâ
- People who are willing to paste yaml replacements into their automations/scripts and not need to be âbreast fed in the school yardâ, refusing to deal with anything other than the GUI
A consequence of this is that I shall be monitoring âVery Closelyâ the development of HA and at the point where it ditches âyaml that I can understand and interact withâ (say at version 1.00.0 or whenever) then I will be rolling that back to version 0.999.99 and cutting off any further updates.
We are in danger of trying to make a VCR (a device that seems quite techy but has a limited function because it only has to do one thing, so just choose from this list). It means that we are allowing people access to tools âtheyâ donât understand.
Itâs quite common to find someone here (on the forum) that wants to set this light to Indego but only on a Wednesday, If the preceeding Monday two weeks before was a public holiday, if the sun is up and itâs not night and itâs a Thursday tomorrow and itâs between 00:00 and 24:00 and Light X is on (but not off) and its not green and not yellow and not purple but it does have to be white, Oh ! and it needs to switch - exactly 2 days and 14 hours and 32 seconds before the sunset in 3 days
They do not now how to compress their logic, state it concisely and tackle it one step at a time
AND the AE is not helping with that
But because they can switch on a light, they feel that the logic above is doable and itâs âyouâ who are being stupid/obstructive/rude because âtheyâve got it ALL in the âGUI Automationâ - itâs simply that it doesnât workâ and clearly this is âyourâ fault because youâre stupid.
The likes of pnbruckner, Taras, Tom, Marc, petro, finity and Many Many Many more try to feed tidbits, explain in detail whatâs happening and why, how you should construct your statements. It takes time but they have seen some truly great improvements in many members (but then you see others come back the very next day and say "yes but can I have it ânot orangeâ too ? ")
BHONâs (Black Holes Of Need !)
Itâs a mixed bag !
I think the hurdle of learning yaml requires âsome commitmentâ, âsome studyâ, and the requirement to interpret things from the âcook bookâ and adapt these to their own problems (to me this was a major source of satisfaction) As a consequence the logic âseeped inâ with it.
Education is NEVER wasted.
I am quite saddened by the âseemingâ direction this is all taking.
You crack-me-upâŠIâm looking more at something POST 0.88.xx and PRE 0.99.xx myself. I want to avoid the rot that set in (for my particular config and use case) POST 0.10x.xx right through till the present 0.109.xx releases. Would you be able to recommend anything around there as being a good solid/stable release? My config uses modbus extensively and POST 0.88.xx and PRE 0.99.xx brought some very useful modbus advances.
Iâm now on 107.7 and I am not really happy how that is performing but no way am I going forward in the present climate here.
Cheers and lets hope there may be better things ahead!
The number is purely arbitrary and is obviously dependent upon the individualâs current integrations and their perceived ability to navigate the release and general comfort with it. (I know of some people who gave up and locked at 0.73 etc).
You are in a very tough spot as Iâve dipped into the modbus threads (Iâm not using modbus, just for general interest) the guy whoâs writing that seems quite level, accommodating and open. He is striving to accommodate some of the issues you (in particular I think) have raised. So âthatâ may come back.
But X10 was considered a good bet 10 years ago also.
Same as by 1.22.04 (another made up number) the AE will be so brilliant - âwhat the hell was I pratting about with yaml forâ I canât predict the future. All I know is Iâm âcurrentlyâ not comfortable with the current course and some of the baggage weâve collected and the passengers weâve lost along the way.
Iâm not that stupid that I canât understand the aim and will be setting up a test instance (following locking my production instance) to monitor if nirvana has been achieved.
@Mutt yes I stopped at 0.74.2 I think it was for a long while.
There have been many times I wish I had just stopped there and left the rollercoaster to braver souls than me. My UI was exactly the same, my logs were clear of annoyance and, cpu and memory usage were better. Except for Nabu Casa (which I think is fantastic), none of the features tacked on have been a huge leap forward IMHO.
Whats involved in setting up a test instance? For me I need to test my modbus devices which do not respond in a friendly way to a second âMasterâ reading or writing simultaneously? How would you manage that do you think?
Steve,
Test instance : - very easy for me, I just have a spare pi and a spare z-wave stick and a spare z-wave device that will accept actions, mqtt items should be transparent and lan (ip based) entities also (TV is connected, kodi is connected etc.). So I can test creating automations, most of the config is just a copy of my production instance.
For you the test instance might be more problematic as the costs of⊠$ „ ⏠£ Are not inconsiderable (do ya wanna buy some X10 gear ? )
(I donât have any X10 )
A lot of guys here run multiple instances either in different v machines, proxmox venvs, dockers etc. @Mariusthvdb runs 3 as does Taras, @tom_l is working in the Antarctic at the mo, so Iâm pretty sure that he has a pi (or similar Diddy kit) with him.
I even know of a guy that forwards different ports to different instances so he can connect remotely to all (I donât and canât recommend that but it fits his needs)
Iâm sorry if I missed it but how do you run your HA now? HassOS, Docker, venv?
Perhaps Iâm really dumb but I have no idea what ANY of this thread even means. What practical effect will this have for me turning my lights on at sunset? Or my coffee maker in the morning at 7am? I donât even understand what a device trigger even is?
It is supposed to be an easier way for a halfwit (now the target home assistant demographic apparently) to add automations. In reality it is redundant, poorly thought out (see device_id issues above) and is pretty much undocumented. It was incorporated in v0.99, https://www.home-assistant.io/blog/2019/09/18/release-99/#device-automations
and does it save in automations.yaml or is it spirited off to .storage?
I tried to create one and none of my devices were available. Skipped and I can select some devices - all my sonoff switches for example - but none of them are in there with their âfriendly nameâ soâŠ
not impressed.
It saves to automations.yaml, but it is rather unreadable. Just a random id, so you canât figure out what de device really is.
You can because the entity id is also in the automation. The device id appears redundant because of this but is probably required to keep track of the automation in the UI.
I only tried it once, when the feature was introduced.
@finity No probsâŠI see you are very busy hereâŠI feel my main problem is testing modbus which is not as easy as having two HA instances running on the same network which read the same devices. Modbus slaves donât play well with two masters (HA runs as a master).
I use a docker running HA Core atm.
Biggest other problem is I dont have any spare modbus equipment so I would have to pick up something to do any meaningful testing.
Sorry I did not reply earlier @Mutt but I did read your post and thanks for your answerâŠI was digesting it and then promptly forgot to respond. Got carried away with polls and stuff here and a busy life at home and I only just remembered after finity quoted me above.
Yes for me I would need to purchase some extra gear to test with for sure. Not in a position to do that at the moment. Iâll give it some more thought and post again when I have something to report.
Cheers!
literally up till a couple of days ago Iâd solely configured my automations in yaml by hand⊠Iâd have no clue how to do some of the more complex ones in the UI???
I recently had to use the UI because I bought a couple of ikea remotes and HA gave me no tools to figure out the name of the event when the various buttons were pressed⊠most annoying so I used the UI⊠at that point the UI âpollutedâ my automations.yaml with these pointless IDs and also stripped out all my âcommentâ lines⊠thanks UI great
Itâs pretty easy to set up a second instance in docker.
Just use the same Docker run command and just change the container name to something else along with designating different volume mapping for the configuration files. At that point itâs as easy as going into the config directory and changing the http port from the default to some other unused one.
as far as the Modbus part I canât help you at all there.
Iâm on a QNAP and I use ContainerStation to install and manage the container so I can setup the config folder and I think I can even setup the port as I am creating the container but its the actual test environment to get some meaningful results without coming anywhere near my production environment that has me stumped atm. I understand not many people are able to help much with modbus side of things.
Cheers again!
Maybe something like mqtt statestream/eventstream or remote-home-assistant to âsyncâ the two HA instances could be helpful for you.