Check it with one first, just to make sure it does what you expect.
Then it just might be worth looking at what is in the flows file for the node you have changed and what was there before. Set flowFilePretty to true in settings.js if it isn't already, restart node-red and force a deploy then open the flows file in an editor and find the new node and one of the old ones. If you are lucky you might be able to do a bit of search and replace to switch them all over. Keep a copy of the flows file obviously. Once you have finished then restart node-red.
Just had a look.... I'm not clever enough to do a search and replace on this I don't think....
A bit above me... to say the least... I think I'm gonna have to hold on this node swop for a while...
E
Went a step further too... Have just finished checking all of the wifi switches that are online to make sure they are individual in client name... All ok, no duplicate client names found....
Ed
1 Like
To replace the mqtt-json nodes with normal mqtt nodes...
Steps...
- stop node-red
- backup your flows
- open your .node-red/xxxx.flow.json file in a text editor
- search & replace all instances of
"mqtt-json"with"mqtt in"& save. - uninstall node-red-contrib-mqtt-json
- start node-red
Alternatively
- export all your flows (CTRL+E)
- paste to text editor
- save as "original.flow.json"
- Delete all flows & deploy
- search & replace all instances of
"mqtt-json"with"mqtt in"in the text editor - copy all flows to clipboard
- import into node-red (CTRL+I)
- uninstall node-red-contrib-mqtt-json
- restart node-red
there are slight differences between the JSON of these 2 nodes but nothing that will break anything (i.e. it is enough to search+replace "mqtt-json" with "mqtt in")
Hi Steve,
Thanks for the info, but, a query(of sorts)....
I did a manual insert of the mqtt node alongside a mqtt-json node, copied the relevant criteria across, then put a debug on each node and compared the outputs... There seems to be a bit of a difference between them, whilst they will both operate without errors as the nodes themselves, the downstream nodes have to be "reconfigged" to look at the data in a different way... Or so it seems to me... Might I be wrong?
Regds
Ed
The differences will mostly not matter (the new MQTT nodes have lots more features, but being missing is not an issue as they will default to default values internally)
The only issue I can see is if in those mqtt-json nodes you have used the payload property - you will need to add a change node after the std MQTT node to copy the payload to its intended msg property
Trust me, the effort is worth it. The new MQTT nodes use a much improved version of the MQTT lib and also supports MQTT v5.
1 Like
Yep... You hit the nail right on the head!
And...Of course... In the bulk of them too!!
Regds
Ed
Right....
So I have:
-
Gone through and edited all the old mqtt-json nodes and removed the value in the payload field.
-
Put in change node where necessary after it to allow for the payload field I wont be using.
-
Tested the system as it now stands and it seems to be operating as it should.(Still racking up credits in the Skt dept though)...
Now, the million dollar - The "missing field" under "mqtt in" vs what is in the "mqtt-json" node.... Doing a global replace on the flow file, would I need to do a further edit to include this field and set it to "a parsed JSON object", or will it default to that, as such?
Regds
Ed
Is that what you need. Parsed JSON Payload?
If so, it's easy to add to the JSON when you do the search & replace.
DO NOT FORGET LOTS OF BACKUPS OF YOUR FLOW FILE!
Thanx, Will check it out...
Indeedly.... Will download an export of the flow file, work on it locally, then save it as another name, upload it, then swop it in after renaming the original to a backup name....
Cya
E
Was a bit above my paygrade.... there were some nodes that were using Text string output and some with json out....
Done it manually... All replaced and mqtt-json has been removed from the palette...
E
1 Like
I just hope it helps your problem after all this work 
So far, not looking too good... No major change, but, it is only about 15mins running.... Gone from 420 to 485 or so Skts on graph... Conforms more or less with previous at about 250 Skts increase per hour... Let's see if it flattens out....
E
Well, The good news is..... I haven't broken it further than it is....
Bad news is..... Still the same... 16h10: 434 Skts open.... 18h10: 943 Skts open....
In the interim, I have removed any disabled flows from the system... Also no improvement...
Bugger......
Ed
I wonder, since this process may take some time, whether you should consider running a 2nd instance and do a controlled transfer of your flows from 1 to the other?
I wonder, since this process may take some time, whether you should consider running a 2nd instance and do a controlled transfer of your flows from 1 to the other?
That is a possibility....
Not an easy one to accomplish, as the inter meshing of the two instances would probably argue with one another....
Unfortunately, dissociating a system from its control inputs and outputs would be the only feasible way of doing it, but then, there would be little to no activity per se.... I don't think I would accomplish much by that except having a bit of fun!
I can't help but think, there is something fundamental amiss... Something in the foundational system setup or the way Node Red talks to its "next in line" ....
Any suggestions are worth looking at, more so on the "live" system than anything else....
Regds
Ed
Edit: I am wondering if there is perhaps a "lost node" or "Lost partial flow" hanging around somewhere that is contributing to the problem.... I have no idea how to even try and track that scenario...
Just bumped NR up to the latest ver 1.3.1 to see if any improvement on the Skts problem....
