I was going off of memory and was incorrect. The get history is special I guess it wants its inputs on the msg level, not in msg.payload so msg.entity is what you want to set.
The information is definitely in the information tab all nodes show what they accept as input there.
I’ve tried to solve this myself and have come to “end of my tether” point. Not helped that I started to try using hass-post before finding that it doesn’t work with the new HA authentication. Then came across the the suggestion to use “ha-fire-event” to change a state.
I’m trying to change an input_number in HA. I’m totally failing on this, even just trying to use the ha-fire-event node with an inject trigger.
If you choose not to install the custom integration this package will continue to function as it always has you just won’t be able to use the new sensor and webhook nodes or have the ability to expose event nodes to Home Assistant.
Sensor Node:
It will create a sensor or binary sensor inside Home Assistant that can be updated directly from Node-RED.
Event Nodes (events: all, events: state, trigger: state, and poll state):
Will have the option to be exposed to Home Assistant, and when enabled, it will show up in Home Assistant as a switch. Turning on and off these switches will disable/enable the nodes in Node-RED. This should help people who find themselves having to make input_booleans in HA to enable/disable flows.
Installation of custom integration can be done using HACS or manually, instruction can be found in the README.
Tip:
Filling in the name field in the HA config of these new nodes before you first deploy will attempt to create it with that entity_id otherwise it will default to sensor.nodered_79fba2c4_04342c. Where the random string is the node id in Node-RED. The entity ids change be changed in HA after creating them in NR.
Bug Fixes
call-service: Remove spaces around entity ids for homeassistant domain (564670a), closes #170
These new nodes sound awesome! I’ve been using MQTT as a middle-man to accomplish the very thing these now accomplish. I’m guessing these nodes will actually react faster than using MQTT.
The sensor node doesn’t seem to take INPUT attributes from msg.attributes or msg.payload.attributes. I get errors for the latter:
UnhandledPromiseRejectionWarning: TypeError: parsedMessage.attributes.value.forEach is not a function
at EntityNode.onInput (/config/node-red/node_modules/node-red-contrib-home-assistant-websocket/nodes/entity/entity.js:188:44)
I noticed input attributes are not combined with configured attributes. Instead, input attributes override ALL the configured ones. Having input taking the priority fits with the usual NR pattern, but could it be more precise, and only override any duplicates?
I only ask because I planned to configure all the static attributes in the node, and define any dynamic ones in the payload.
Obviously, either way is very usable (and appreciated), as I could just define all of them in the payload.