I found a regression in the beta1: V4.0.0-beta1: change to bool no longer working · Issue #4638 · node-red/node-red · GitHub
The change node converts everything to bool, if just two values should be changed to bool.
It might be helpful if you built a small flow (Inject -> Switch -> Debug) showing the problem, to make sure we understand fully.
I think you meant (Inject -> Change -> Debug) As the issue is with a Change node.
Indeed I did.
@Colin
You can find the details in the GitHub issue: V4.0.0-beta1: change to bool no longer working · Issue #4638 · node-red/node-red · GitHub
Here is the flow:
[{"id":"7b945e577024a009","type":"tab","label":"Flow 2","disabled":false,"info":"","env":[]},{"id":"ba5a22cdbcc2fcd7","type":"junction","z":"7b945e577024a009","x":340,"y":220,"wires":[["e7d937c74c016290","388cbdbfbc84b326","51821dcea7a40f23"]]},{"id":"e7d937c74c016290","type":"change","z":"7b945e577024a009","name":"to bool","rules":[{"t":"change","p":"payload","pt":"msg","from":"off","fromt":"str","to":"false","tot":"bool"},{"t":"change","p":"payload","pt":"msg","from":"on","fromt":"str","to":"true","tot":"bool"}],"action":"","property":"","from":"","to":"","reg":false,"x":430,"y":220,"wires":[["c6c155046e530222"]]},{"id":"b95a1eacb7e8dca5","type":"inject","z":"7b945e577024a009","name":"","props":[{"p":"payload"},{"p":"topic","vt":"str"}],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"on","payload":"on","payloadType":"str","x":230,"y":180,"wires":[["ba5a22cdbcc2fcd7"]]},{"id":"034b2af45fdfdef3","type":"inject","z":"7b945e577024a009","name":"","props":[{"p":"payload"},{"p":"topic","vt":"str"}],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"off","payload":"off","payloadType":"str","x":230,"y":220,"wires":[["ba5a22cdbcc2fcd7"]]},{"id":"e12db9eb3e02fbce","type":"inject","z":"7b945e577024a009","name":"","props":[{"p":"payload"},{"p":"topic","vt":"str"}],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"error","payload":"error","payloadType":"str","x":220,"y":260,"wires":[["ba5a22cdbcc2fcd7"]]},{"id":"388cbdbfbc84b326","type":"debug","z":"7b945e577024a009","name":"debug 11","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"false","statusVal":"","statusType":"auto","x":440,"y":260,"wires":[]},{"id":"c6c155046e530222","type":"debug","z":"7b945e577024a009","name":"debug 12","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"false","statusVal":"","statusType":"auto","x":620,"y":220,"wires":[]},{"id":"51821dcea7a40f23","type":"change","z":"7b945e577024a009","name":"to number","rules":[{"t":"change","p":"payload","pt":"msg","from":"off","fromt":"str","to":"0","tot":"num"},{"t":"change","p":"payload","pt":"msg","from":"on","fromt":"str","to":"1","tot":"num"}],"action":"","property":"","from":"","to":"","reg":false,"x":450,"y":180,"wires":[["0a02112ec5e7e162"]]},{"id":"0a02112ec5e7e162","type":"debug","z":"7b945e577024a009","name":"debug 13","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"false","statusVal":"","statusType":"auto","x":620,"y":180,"wires":[]}]
(Have commented on the issue, but adding here for context)
This change was made in response to #4372
At first read of this and the other issue, it sounds like two different desired behaviours - one saying it should always result in a boolean result, one saying it should only set a boolean in some circumstances.
Will look at the finer details to see if there's a subtly in behaviour we're missing - possibly the fix for the other issue is being too strict.
@Colin I don't think this is a new behaviour.
I am assuming your settings.js file has the flowFile setting set to flows.json.
As that is a relative file path, Node-RED will first look in the current working directory for the file. If it is not found, it will then look in the user directory.
So when you run in ~, it fails to find flows.json in ~, so then looks under ~/.node-red-1884 and finds it
When you run in ~/.node-red it finds flows.json in that directory so uses that.
Yes, you are right. The reason my test with an older version of NR was that its flow file was flows_.json, so flows.json did not exist in the current dir. So it has apparently always been like that. Whether this is desirable behaviour or not I don't know, but it isn't a v4 issue.
Fix identified - Fix handling of subflow config-node select type in sf module by knolleary · Pull Request #4643 · node-red/node-red · GitHub
1 Like
Sadly this doesn't seem to have helped, assuming I don't need to repackage the subflow. With NR 4.0.0 Beta.2, after installing colinl/node-red-dropdown-cdl, restarting node-red and refreshing the browser, if I place the node on the flow and open it I get
bootstrap-autofill-overlay.js:4710
Uncaught (in promise) TypeError: Cannot read properties of null (reading 'previousSibling')
at CollectAutofillContentService.recursivelyGetTextFromPreviousSiblings (bootstrap-autofill-overlay.js:4710:30)
at CollectAutofillContentService.createAutofillFieldLeftLabel (bootstrap-autofill-overlay.js:4603:39)
at CollectAutofillContentService.<anonymous> (bootstrap-autofill-overlay.js:4174:40)
at Generator.next (<anonymous>)
at fulfilled (bootstrap-autofill-overlay.js:4104:58)
It looks ok in the editor, but if I select the group, Deploy, and re-open then it appears not to have saved the group. In fact if I export it then I see this, with an empty value for the selected group.
[
{
"id": "16e16813cf41e25f",
"type": "dropdown-cdl",
"z": "eff7ca5fd9394ba5",
"name": "DROPDOWN CDL",
"Group": {
"type": {
"type": "ui-group",
"value": ""
},
"value": "411b8fe1ec44dbe2"
},
"label": "Select",
"options": {
"type": "json",
"value": "[\"A\", \"B\"]"
},
"topic": "",
"waitingColour": "red-lighten-5",
"x": 230,
"y": 2820,
"wires": [
[]
]
}
]
@Colin okay - will take another look. It was certainly hitting the same error you were with my test subflow module and confirmed the fix resolved it for my module.
That stack is curious - not sure where bootstrap-autofill-overlay is coming from.
The bootstrap-autofill error appears a couple of seconds after the node edit dialog appears, if that is of any help.
I have tried with a much simpler subflow, with just an ui-text node, and it shows the same behaviour. If you put your test module somewhere I could give it a go, which might tell us something.
Sorry, I misinterpreted what I am seeing. It is in fact correctly saving the group (I was looking at Group,type.value instead of Group.value). The issue here is that when I re-open the node it is not recognising the fact that a group has been configured, and is showing the default group again. It still doesn't appear in the dashboard panel though. It does appear in the dashboard.
