Excuse me for my ignorance, but does this state anywhere that “beta means” that it won’t function? Having hickups occasionally and not functioning is two different things. When Gmail was in beta it functioned fine.
Maybe they should state that things won’t function properly at this checkbox and not that things will get better over time - because this is two different way of communication. If it is stated that “beta” for them means serious malfunctions, then I would have not ordered it, simple as that.
Also when I ordered the product, the shipping estimate was April. Now we are almost in August. I got the product in July.
If I know these issues in advance (this was not communicated at the time of ordering) then I would have simply chosen something else. I’m sure I am not only one who feels cheated. Also I am sure this post of mine will be moderated out, because Athom simply can’t handle the truth and critical voices are silenced.
@gero
Please keep in mind that this is just a community forum, not the Athom support desk.
If you have issue you should go there, as shouting everything in this topic won’t help you, nor the community as they can’t help you with most of your issues Z-Wave related.
Beta is a wide spread word and can mean anything, from not working (properly) at all (like now is the case for certain situations with Z-Wave) to “it should work 99.9% of the time”
Athom is dealing with a new Z-Wave chip which is in itself also still in beta, hence why they are working with the Z-Wave manufacturer themselves to try and solve this issue.
If you can’t handle the still imature product, then feel free to leave instead of filling this community with this “shouting into emptyness hoping to be heard”
Well, as the official support is not reachable, it is hard. Furthermore they read this forum. All in all we went off topic on this. I will spare you from my frustration in the future. I will look for alternatives and send this product back if the issues are not getting better in the coming few weeks.
There’s two ways to look at it; 1) it’s beta yes, so you can expect anything and nothing. 2) the beta ends in 5 days, so in 5 days you have every right to complain about it.
A way for developers to release to a wide ecosystem and config base in order to find bugs issues and performance concerns.
Though the original terminology tends to be for waterfall. For athom it feels more about iterations over ACs defined.cycling through adding features, fixing bugs until the mvp is achieved and stable.
By the way, back on the original topic, I was reading back last night and I had previously missed from @Youri_Pasternak 's post yesterday there’s some meaningful information here about the issue indirectly from the Athom support team.
Using Google translate to get an imperfect but usable translation of their response to Youri in Dutch:
As I mentioned before, some devices don't get a reporting value set when adding. This issue only affects Homey Pro (Early 2023), this does not apply to Homey Pro (2016-2019). Because this value is not set properly, you do indeed get these absurdly high values. It's not a strange problem on your Homey Pro, as mentioned before, we know what the problem is, where it comes from and how to solve it.
Would you like to reset the reporting value, with a small adjustment (eg 601 instead of 600)? If all goes well, this small adjustment will try again to write this value into the device. If you then want to restart Homey Pro again, this will reset the Rx values to 0 and it will be easier to see whether the device is still sending too many signals through the network.
Should the Rx value be absurdly high again, would you temporarily remove the sensor from your Z-wave network?
Would you perform this procedure for any device that has a high Rx value? Ultimately, the intention is that all devices continue to transmit the signals in a normal time interval.
I take from this that:
the issue is caused by the Z Wave device not being properly assigned a reporting frequency value when it’s set up
the point about changing the value to 601 was not about reducing the frequency of reporting to reduce noise, but simply to force Homey to try again to set any reporting value on the device - literally any value would work as well for that purpose
Athom knows what is causing this issue and how to fix it - from which I take it that this is on the ‘to do list’ quite possibly between now and public release
One thing Athom can see that we can’t is overall how many users are experiencing this issue vs. the others they are working on. Maybe the relative prioritisation makes sense in that context. I still think a lot of bad feeling could have been saved with a tiny amount of work simply by Athom adding what is clearly a known issue by them to their list of known issues. But at least this gives me some hope that it is just a matter of (hopefully not much) time before this is fully fixed.
I admire your optimism JD but RC142 has no reference to Zwave.
Going live as a finished product in 4 days with stable firmware, or getting sent back to them.
My installed sensors are exactly the same as they were when I ran the 2019 Homey, nothing changed when I came over to the Homey 2023.
I can switch back and everything works just fine, not even a hint of a chatty device causing issues.
For me the issue is firmly in Homey, not my setup, and changing device settings to make them less chatty only masks the problem, not fixes it.
By the way, I don’t think there’s any doubt the issue is with the homey pro 2023. That’s precisely what that support response above said. It’s a known issue, just annoyingly hasn’t been added to the known issues log.
Had an email from vesternet today, uk home automation retailer, to say the homey is now available for everyone to buy.
The clock is ticking for sorting this out.
This is driving me insane. I went in to developer, saw a couple of cuprit chatty devices with request in the tens of thousands.
A pattern I see is that they are devices with apps that are not supported by Early23 and are orphaned. I have removed them from the homey app, but they still appear as “unknown” devises in developer site, and racking upp thousands of pings. I have now factory reset all these devises, and disabled any flow involving them. but still "too much z-wave traffic.
Today I spent some time to try de solution offered by Athom:
Homey was off for at least 24 hours
I removed batteries from ALL sensors and turned homey on
1by1 I put back the batteries, adjusted the update settings, saved, put in learning mode to ensure its saved and so on for all my sensors
just to be sure, I updated the update settings for powered zwave devices as well
after all this, the Rx values remained low and traffic was low. All seemed to work
then after +/-6 hours ( I did not change anything), all sensor values (Rx) went crazy again, too much traffic and I see again 30 messages per second in the logfile
I emailed now Athom again, seems like a random thing with homey. Finally tomorrow the beta ends
You have to wake up the sensor first and then save the changed settings.
I’m still wondering if sensors powered by battery’s are actually sending 30 data per second, or if Homey is multiplying the data from the sensors?
Is there a clear answer to this?
It is not sensor’s fault, as they work perfect with the old homey. I am back again on the 2019 pro, and no issues. If it was sensor’s fault, 2019 homey would have collapsed too.
It’s Homey duplicating. I have compared all logs (2019 vs 2023) and it only happens on the 2023. Also, I doubt the sensors are even capable of sending the same (!) message 30 times within one second.
But this must be done the other way around. First you have to wake up the sensor and then save the changed setting.
Fibaro uses the term “Learning Mode” for the inclusion and exclusion process.
When changing the configuration, Fibaro also calls the procedure “Waking up”.
Just my 2 cents…
