Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Node-RED Trigger from Automation doesn't trigger (right) output path #1712

Closed
kristian opened this issue Dec 21, 2024 · 5 comments
Closed

Node-RED Trigger from Automation doesn't trigger (right) output path #1712

kristian opened this issue Dec 21, 2024 · 5 comments

Comments

@kristian
Copy link

kristian commented Dec 21, 2024

Describe the bug

I noticed that when I use the nodered.trigger in automations, it doesn't seem to trigger the right output path. For as far as my testings go, it seems to always trigger output_path 1 if that makes any sense. I am not very familiar with your code base, but looking at:

I found that output_path seems to be parsed as a boolean instead of a string here:

output_path: Joi.boolean().default(true),

And as every non-empty string evaluates to true in JavaScript, essentially the output_path is always "true" as the default is a string "0" so true. This results in always choosing output number 2. However also the rest of the code doesn't seem to match the documented behavior of being able to specify a comma-separated list of output paths. I started to suggest a PR (kristian/node-red-contrib-home-assistant-websocket@main...kristian-automation-trigger-fix), but then I became confused, because the right logic seems to be implemented here:

If I should go forward with my PR I would need some advise on why there are two different implementations (with some undocumented properties like skip_condition as well)? Any help would be appreciated! 👍

To Reproduce

Create a automation, use a node-red trigger, observe that mostly output path 1 is chosen.

Expected behavior

The output paths should behave as documented.

Screenshots

No response

Example Flow

No response

Environment Information

Version: 0.73.0

Home Assistant version: 2024.12.5
Companion version: 4.1.2

Node-RED version: 4.0.3
Docker: yes
Add-on: 18.1.1

Node.js version: v18.20.4 x64 linux
OS: Linux 6.6.66-haos x64

Additional context

No response

@zachowj
Copy link
Owner

zachowj commented Dec 22, 2024

EventsHaNode.js is exclusively used for the deprecated entity node. The new format, as documented here, appears to be functioning correctly based on my tests.

Do you have an exported example that doesn't work for you?

@kristian
Copy link
Author

kristian commented Dec 22, 2024

Hey @zachowj, thanks for the quick response! Ah okay, so essentially also other nodes are exposed as switch entities to Home Assistant as well, I see.

I noticed that I can only select switch entities when I create a Node-RED trigger action. Thus I started to use switches. Are you saying switches and stuff like binary sensor are deprecated and only the nodes you mention here are „current“? Or does your statement only apply to the nodered.trigger? Thanks!

@kristian
Copy link
Author

Mhm, I just went through the list of nodes you mentioned documented here. Maybe I don't get the idea, but essentially I just need an "input node" that can be triggered from nodered.trigger, as I want to "call into" Node-RED from Home Assistant. So far I created a switch which was then exposed to HA as a switch entity and I was able to interact from my HA instance to Node-RED easily. Now with the new exposed nodes you shared, I don't get the idea yet? Is there a basic "placeholder" node available, that I can just use as a inbound trigger to Node-RED? Seems all exposed nodes fulfill a function that I don't need them to fulfill / have no use for. Or am I getting the wrong idea? Thanks!

@zachowj
Copy link
Owner

zachowj commented Dec 22, 2024

The switch node differs from other nodes exposed to Home Assistant because it retains its original structure and hasn't been updated to align with newer node types. The main distinction is that you can't select the output for the trigger data—it depends on the switch's state. If the state is "on," the data goes out the top output; if "off," it exits through the bottom output. You can find an example of using the nodered.trigger service here. You can trigger the flow and send custom data but are unable to choose the path.

Do you need to only trigger the Node-RED flow from Home Assistant, or are you looking to send custom data as well? The button node allows you to initiate a flow directly from the Home Assistant UI using the "button.press" action. If custom data is required, you can fire an event in Home Assistant and use the events: all node in Node-RED to start a flow based on the event name, including the custom data.

@kristian
Copy link
Author

Okay this explanation sheds some light on the current behavior! Thanks!

Do you need to only trigger the Node-RED flow from Home Assistant, or are you looking to send custom data as well? The button node allows you to initiate a flow directly from the Home Assistant UI using the "button.press" action. If custom data is required, you can fire an event in Home Assistant and use the events: all node in Node-RED to start a flow based on the event name, including the custom data.

Ok, this makes things significantly easier. I thought too complicated and wanted to use the nodered.trigger by any means... I just thought "well I want to trigger a Node-RED flow, so let's use the built-in action from it". That I simply can use a native button.press action, didn't cross my mind at all. 👍 This is the most easy option in my opinion and as you said, also sending a custom event makes perfect sense.

For more complex use-cases a dummy "inbound trigger" node would have been nice. A node that you can specify the number of outputs on / without any inbound connectors, so you could use nodered.trigger, to choose which outputs to invoke, sending data. Maybe just as an idea for any future update.

Thanks again for the explanation. I will close the Issue & my PR. Have a good one @zachowj.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants