Ok, going to try and keep it simple. I use various change nodes to take the payload from a previous node in the flow, search for things like ‘on’ or ‘off’ and change payload to a boolean True or False. Its working fine in a number of nodes all fine.
Now i am taking my Tesla door lock state which is ‘locked’ or ‘unlocked’. Try to change to boolean ‘True’ or ‘False’ but get a weird result. If its locked, the payload returns a ‘locked’ and i am able to change to ‘True’. But if the car returns a payload of ‘unlocked’ then the change node returns a boolean of ‘untrue’…what the heck? where does that come from?
Use a switch node to sort then change node to boolean value. It is just changing the word locked to true by the time it hits the second rule payload was changed to untrue.
thanks @Mikefila, will try this later today. Maybe my lack of knowledge but would be interested to know why its changing to untrue when all my other instances of this logic work fine. Good idea on the workaround though, going to give that a try. thanks
Actually, thinking about it i cant do that. I am using a Boolean Ultimate logic node directly after that assesses the inbound payload (and it remembers persistent values) so using your method i would have two switch nodes needing to feed the Boolean Ultimate logic node for each condition i am checking, hence would always see both true and false.
followed by one example of the alternate method to show what i mean…it will see both persistent states so i need to feed the Boolean Ultimate node with a single payload (true or false)
thanks @Mikefila, will try that tomorrow when i get a chance. Could you explain why this order would work but the other way round does not, i dont understand.
Its great if it works but trying to improve my knowledge of node red so understanding these things as well as fixing them is always a bonus for me.
It goes through the rules in order from top to bottom.
When a payload of locked hits the first rule it will not match unlocked and be passed, unchanged, to the second rule which it will match and then changed to true.
When a payload of unlocked hits the first rule it will match and therefore be changed to false. Then passed to the second rule in it’s changed state as false and will not match the second rule.
Hi @Mikefila, i have just managed to make the changes and it seems to work swapping it around which is great, thank you!..unlocked now reports false and locked reports true
i have read your last message and understand what you mean about the payload then being changed, but surely then it should not work for the other way round, i.e. when locked is passed to the first rule and does not match, then false is passed to the second rule which would not match…or am i missing something.
When you are looking for locked it can be found in both messages “locked” and “unlocked” and for our purposes here both are considered a match.
When you look for unlocked it can be only found in the unlocked message.
This is a switch, first rule looks for unlocked if it doesn’t match it passes it down the line. You’re thinking of a conditional that would stop the message.
thank you so much, i understand now…i was not aware it would consider part of the payload as a string match…makes complete sense now. Thank you very much for not only helping me solve the issue but to also learn how this works in more detail!
