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.
Had exactly the same experience when I first started using home assistant. I have avoided the UI like the plague since. Love how it arranges all the automation yaml in alphabetical order to make it as difficult as possible to read if you are human 
Aren’t those remotes zigbee protocol?
If they are you can go to the developers tools->events tab and start listening for “zha_event”.
Go to Developer Tools → Events, enter * in the Listening to events box, press start listening. You should now see an event every time you press a button on the remote, you can then use these events to create your automations in YAML with the event trigger. Take a look here (I know it’s for deconz, but the principle is exactly the same to create automations from events)
Thanks, I did try that and nothing… also listening to deconz_event did produce results but nothing referring to what button was pressed
Is your device integrated through Deconz? Can you please show the event you see, it should contain all the information needed. There will be no name for a button press, instead there will be a 4-digit code like 1002, 1001 etc.