I haven’t used the fibaro plug. It does have extensive configuration that should be able to restrain the updates. Look at parameter 12, it default to 30 seconds. Try to get one working well and once you figure out the formula apply it to the others.
Let it run for a while, rerun the report to see how it improved.
Giving it a try now. Set it to 10 minutes to give it a test. It’s a bit difficult to see in ZwaveJS ui what param is what. But I think I got it.
Nice. When I pulled my meters off my network instantly ‘felt’ better. After a few strategic repairs (some of the routes that always caused me issues you probably know which ones yours are) and man it lit up. Hope it helps you.
Pulled meters from the network? You mean that you removed the power plugs?
So far I have set the most busy power plugs to report every 10 minutes instead of 30 seconds. I can see in the logs, that there is already a lot less traffic than before. Param 12 seems to do something here. Now going to keep an eye out to see if it will be more stable.
Appreciate all the help I get here from you guys! Thank you so much! 
What I do find strange is, that for 2 plugs I had to do a re-interview because ZwaveJS UI did not show all params in the interface. It’s a bit strange to see it lost params.
Yep I am now metering at my panel (SPAN) and they transit the data on an independent wired ethernet network isolated from the rest of my traffic.
My ZWave network is now for command / control, power is all coming through SPAN at the breaker box level
(I lost my electric panels during the power issues during that Texas snow event a couple years ago and while replacing the entire electric system I went Cadillac)
Not familiar with SPAN. I live in the EU. So it sounds like something we don’t have here. 
I think Schneider electric has solutions for the EU. Just think central monitoring… but we’re quickly out of scope for this thread there.
Will look into it.
@NathanCu @PeteRage Thank you very much for the help and all the tips. I have set param 11 and 12 on the Fibaro power plugs to report less frequently. The amount of traffic is greatly reduced now.
The controller is stable now for 18 hours. It did not jam, nor was it briefly unavailable. The network is stable and it responds even quicker than before. 
No nodes have suddenly gone offline.
I keep my fingers crossed 
, but I think that adjusting the amount of reporting fixed the problem. 
Sounds good, keep an eye on the traffic and keep working to keep it low. A good practice is to track the RX sensors and put them in a history graph.
When there is alot of traffic, this increases the likelihood of message colliding with each other which causes the messages to be retransmitted, generating more traffic and potentially causing more collisions, which generates more traffic, and eventually the whole thing collapses (this will happen regardless of the controller being 500,700,800.) In the 700 and 800 series controller there seems to be a bug that manifests when the network gets into this condition.
Thanks, will sure keep an eye out for it. I have learned a lot yesterday. Wasn’t aware of the amount of traffic at all. I just extended my network bit by bit.