So let me prefix this by saying I am a heavy node red user. I switched over all of my automations and scripts at one point because I found it a lot easier to write my automation there.
One of the main reasons I made this change is because of the wonderful “debug” node that Node RED has. You can drop this node in and attach it to any point in your flow and get the entire working state dumped out to the sidebar as JSON.
I think HA should have a similar feature. There is a lot of local state available during processing of an automation such as the entire trigger variable and the values of any passed in data in scripts. Some actions even create local state now such as the repeat action. This information can only be accessed while the automation is running and its difficult to figure out and remember the schema/syntax you need to use to get at it (especially since it varies per trigger type and can get quite extensive with some types). Having a debug action that can just drop all local state for you to view somewhere would be incredibly handy.
I also think it would be useful if a debug action could be used to drop the entire state object of a particular entity in the same way. This is not quite as important as the local state since you can generally access this info from dev tools. But there is some info such as last_updated, last_changed, etc. that doesn’t appear there and can be used in templates. Also if your automation/script itself triggers a state change then it would be great to be able to drop the state of that entity to debug before the triggering action occurs.
What do you propose it would look like in an automation or script?
For example, I currently dump an entity’s state, or desired attribute, value by calling persistent_notification.create. Here’s an actual example from something I was testing recently:
I’m hoping for something that can display me more then just text. Like I would really like a way to dump out and view the entire trigger object or the entirety of a particular entity and what it looked like at a part of the script. It should also be able to dump out any given text value or the value of a particular template but as you point out there is already ways to do that today.
As for UI, I’m kind of imagining some sort of debug panel that would be available to you in the automation/script editor UI so you could fling objects or values to it. That way you could press execute or run or just keep the tab up and trigger your automation/script somehow and see the debug data as those steps are reached. Or perhaps it could be a tab in developer tools to keep a running track of debug events that are flung to it from across all automations/scripts.
In either case I would imagine this debug UI working similar to the MQTT developer tools. Where you can sit on that UI and listen for those events but if you leave the UI then it stops listening. This way debug actions would be skipped during all normal execution and only acknowledged when you are actually doing debugging.
Just want to point out the procedure for people who are unfamiliar with Node-red. You must connect Debug nodes into desired locations within the flow before you can gain any visibility (and, at least until the most recent release, you have to tweak each Debug node to display the entire message object).
When your flow executes, each Debug node posts its monitored node’s message object … which is a long-winded way of saying ‘dumps the variable’s value’ … into a Debug window which is scrolling list of information. Very handy but you do have to add those Debug nodes (sort of like sticking a logic probe into a circuit to display its waveform; you only see results where the probe is touching).
The only way to achieve this in Home Assistant is … kind of similar! You have to “insert” service calls in your script wherever you want to dump the value of an entity’s state or attributes. Where you direct this dump is your choice. Persistent notifications are adequate but you can also write directly to the log using the Syslog integration or to the Logbook (service: logbook.log). In both cases, the messages persist long enough to help debug the problem.
EDIT
I overlooked to mention an important advantage of Node-Red’s Debug node as opposed to using a service call in Home Assistant. A Debug node can dump everything coming out of the node it is monitoring. You have to ask it to do that (and its the default in the latest version). Otherwise, it just reports one parameter, sort of like just reporting an entity’s state but none of its attributes.
In contrast, the service call in Home Assistant will need a template to display whatever it is you want to see. So there’s a more work involved in writing the template. Fortunately, to save time, you can copy-paste the template elsewhere for other debug tasks (then adjust it as required).
Yes, this mode is really what I want. That’s why I was specifically mentioning dumping out entire objects.
Can you just use templates? Sure. But if your purpose is to discover what is available on the trigger object or a state entity because you don’t know the full schema of the thing then its tricky to do that with templates. You’d have to recursively loop through all the fields and recreate JSON as a string. And if you want to maintain type information so you know what is an actual datetime/number vs. a stringified version of those that’s even trickier (but can be important when templating).
I would also point out that another advantage of the debug node is the fact that you can just leave them in there without issue. Since they are specifically for debug they only function when you are in fact looking at the node RED window doing debug. If you use syslog or persistent notifications then you have to add and delete them every time, otherwise you fill up your notifications or log with debug messages when things are working normally. This is why I would like an explicit action so it can be left in without issue and only function when you are actually doing debugging and looking at the debug UI.
Although this second point could also be handled with a disable option so you can disable that debug step when not in use.
Not sure what you mean here. The Trigger State Object is well documented and the entity that you’re attempting to debug reveals itself in Developer Tools > States so the information is available. Now, if you want to see that in one place then, yes you’re right, it can’t be done now.
Comment them out. Effectively, you do the same thing in Node-Red when you disable a Debug node. Like the commented-out code, the Debug node is still displayed in the flow.