Homey pro 2023 - zwave too much traffic error?

as stated before, removing the chatty devices, will return your zwave network to stable again, it is a temporary solution, but it works.
the main culprit in my network were the very old zwave devices, (fibaro) whom i cannot update to the latest firmware.
I have removed 4 chatty devices, and the other 100 are now happy talking with each other.
Also what i have done, if a zwave device reports a failure i stat a countdown, and try again after 5 minutes, since then no further issues.
but still i would like to use the 4 removed devices, but i suspect that is patience…
Moral, please be patient, you bought a Beta product…

1 Like

What is the definition of a chatty device?
All of the devices are equally ‘chatty’ from what I can see. These are fibaro dimmers 2 (1 year old) and fibaro movement sensors (1 years old). Removing them all, would mean I have no devices to be controlled by homey.
What was the difference in your case between chatty and not chatty?

look here, https://tools.developer.homey.app/tools/zwave look @ Tx Sent, and remove the top offenders.

I have removed the devices with 400 and up…

the time when you have bought it does not matter, with regards to fibaro, the firmware does, that is my experience…
you can sent them back to robbshop for instance to have them updated, beats buying new stuff, but still to expensive for me (about 7.50 a piece)

I am now 4 days and 6 emails further with Athom, but I don’t see that Athom recognizes this as a general Homey problem. For now they are responding to me to set the sensor report time higher (which I told them I already done), ptp, send screenshots of zwave (which I initially also did 3 weeks ago) etc.

Thanks Pixi also for your suggestions, but all of my devices are 400 and up…

It’s a temporary workaround for people with just a few devices. I have 120+ Z-Wave devices, of which at least 20 are causing the error because they are ‘chatty’. These are roof windows, lights, roller shutters, sensors, etc. It’s no option to just delete them and hope for the best. They are working fine on the Homey Pro 2019 and Athom should be introducing a fix soon.

On the other hand; all of the devices show 30-40 of the same messages within 1 second in the log, which makes me believe the problem is not just these chatty devices but Homey itself.

Sharky, you only have one sensor and one dimmer/switch. Rest is mostly blinds, who usually dont send information to homey.
I think that is what is why you are safe.

Sensors send all kind of information (temp, lux, movement) and dimmers limited but still (usage power).
What I read here earlier would make sense, if homey is repeating all received information 30 times per second, it will crash itself.

I bet if you install few more sensors sharky, you will get the same.

Yes, but this is not about me - it’s about the sharing the relevant screenshot for those of you, who has problems :wink: So far I haven’t seen any single in this thread.

I asked for some news last night and support told me “we don’t have time for you right now but probably they are working on it. Just keep an eye on the release notes”

I know they are busy, really, but for such a big issue there should be a little more insight and communication.

1 Like

Trust me, Athom has it all. Not only from me. I have shared it before but here again a screenshot, which is just a small portion of my devices. A few minutes after restart of the 2023. This already shows at least 4/5 devices with too much communication. But! It shows the RX number Homey THINKS it’s communicating. Homey is actually itself duplicating messages which makes Homey believe the RX is so high. This is confirmed when (1) looking at the log, which shows the same message from a device displayed 30 times within one second, and (2) because it doesn’t happen at all on the HP2019.

Fully agree with Martijn above and screenshots below of 15minutes of homey pro on with sensors report sending time every 600seconds setting.


2 Likes

Great but this isn’t about Athom, this is eventually about Community helping to Community.
Why not everyone has the same problem ? What is the culprit ?
Maybe there will be soon fix available but you all know Athom is checking this case very deeply with Silicon Labs, the company behind the ZWAVE chip - EFR32 ZG14 microcontroller we have in our HP23.

Not very useful to see portion only but I understand you have 200 of devices, which is possibly the biggest ZWAVE network here, so taking screenshot of them is a pain. Btw, if you are using HP23, I would restart again after while to recover from “Prev. last working node” on Node 31, while Node 15 seems to be Unreachable (try TEST) and still, there is quite a lot of RX already for them, so possibly Node 15 and 16 could be misbehaving (or the ZWAVE chip misbehaves with those two)

Well, you are not using HP23 actively, that’s why you shared always only short after restart ? Anyway.

@Youri_Pasternak , I would suggest to turn of Nodes 2,51 and try to repair Nodes 80 and 81.
If you keep it without those 2 and 51, does the situation stabilize ?
Also I would try to reinsert batteries into Nodes 56,59 and 64.

That’s all I could be thinking off.

New try, 15 min again, russian roulette :slight_smile:

1 Like

You did the steps above ? First we need to try stabilizing your network…without it would be really just useless attempts.

This is what Athom is now suggesting which worries me. Hence, I told them I already changed the reporting from 30 to 60 to 300 to 600, and now to 601? Sorry they replied in Dutch:

Zoals ik al eerder aangaf krijgen sommige apparaten geen reporting waarde ingesteld bij het toevoegen. Dit issue speelt alleen bij Homey Pro (Early 2023), dit is niet van toepassing op Homey Pro (2016-2019). Doordat deze waarde niet goed ingesteld wordt krijg je inderdaad deze absurd hoge waarden. Het is geen raar probleem op je Homey Pro, zoals al eerder aangegeven weten we wat het probleem is, waar het vandaan komt en hoe het opgelost moet worden.

Zou je de reporting waarde opnieuw willen instellen, met een kleine aanpassing (bijvoorbeeld 601 ipv 600)? Als het goed is wordt door deze kleine aanpassing opnieuw geprobeerd om deze waarde weg te schrijven in het apparaat. Zou je vervolgens Homey Pro weer opnieuw willen opstarten, hiermee worden de Rx waarden weer op 0 gezet en kan je makkelijker zien of het apparaat nog steeds te veel signalen door het netwerk blijft sturen.

Mocht de Rx waarde weer absurd hoog zijn, zou je dan tijdelijk de sensor willen verwijderen uit je Z-wave netwerk?

Zou je deze procedure voor elk apparaat dat een hoge Rx waarde heeft willen uitvoeren? Uiteindelijk is het de bedoeling dat alle apparaten in een normale tijdsinterval de signalen blijft doorgeven.

But node 81 is still with state Unknown, so are you sure you did all the steps and you did them so quickly ? Because when I wrote to keep it running without 2 and 51 and reinsert batteries 56,59 and 64 (or try running it without them), it takes some time to get it reflected - maybe also followed by reboot, might be wise… I would wait at least about 30-45 min after restart and adding slowly those “chatty devices”, check also their settings (they should have the settings stored but I would re-save them eg. on STABLE network etc.)

I have not (yet) seen the too much traffic error that many have reported but I am following this topic with interest. I have a fairly large z wave network which includes several of the devices identified as being ‘chatty’. I’m not really sure what all the numbers in these screenshots actually refer to but some of those ‘chatty’ devices in my setup do indeed seem to have very large numbers next to them in both the Rx and Tx columns on my dev tools page.

I have been using my HP 2023 for some months now with this setup and current uptime is measured in weeks, so sharing my screenshot as a comparison of a similar setup to others with this issue and apparently some of the same chatty devices but without the resulting issues. Maybe this will help others who know what to look for get closer to some answers or maybe rule some theories out.

1 Like

I also don’t know what ‘unreachable’ means but I still get reports as usual from some of the nodes marked as unreachable (a few I know are ‘dead’ or currently unused nodes that I’ve not got round to removing)

But then you are not on the firmware, which start causing this issue. Which firmware you are on ?

Btw, your motion sensors seems to be pretty “chatty” looking on your data… Nodes 58, 173 - but if there is constant movement, who knows, could be OKay - anyway, don’t upgrade your firmware now :wink: