Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

simplicity_sdk:2024.12.0 #21

Merged
merged 3 commits into from
Dec 29, 2024
Merged

simplicity_sdk:2024.12.0 #21

merged 3 commits into from
Dec 29, 2024

Conversation

Nerivec
Copy link
Owner

@Nerivec Nerivec commented Dec 17, 2024

@Nerivec Nerivec merged commit a86931c into main Dec 29, 2024
8 checks passed
@Nerivec Nerivec deleted the update-2024-12-0 branch December 29, 2024 14:57
@mamrai1
Copy link

mamrai1 commented Dec 31, 2024

So sonoff E won’t work with 8.1.0?

@Nerivec
Copy link
Owner Author

Nerivec commented Dec 31, 2024

These are prelim builds/observations, I'm waiting for feedback from other builders, should get more info after the holidays.
I can only test a few devices myself, so I noted the issues I encountered for now 😉

About the Sonoff, it seems there is a bug somewhere (a default project in Simplicity Studio also has the same issue), but we definitely need more feedback before this can be confirmed (and also if it's just that chip, or the whole MG21 series).

@antst
Copy link

antst commented Jan 7, 2025

I can comment, that startup time became tremendously large, like 3-5 min :)
But after that it seems to work no question asked on 07mg24 with my network of 130 devices.

@Nerivec
Copy link
Owner Author

Nerivec commented Jan 8, 2025

startup time became tremendously large, like 3-5 min :)

What do you mean?

@antst
Copy link

antst commented Jan 8, 2025

startup time became tremendously large, like 3-5 min :)

What do you mean?

with 8.1, when I start z2m, it takes 5 min between moment when z2m reports "z2m: Connected to MQTT server" in the log, and moment when it is actually useable (it can process mqtt ) and line "z2m: Started frontend on port 8099" in the log.
actually it takes 5:30. I can re-try flashing 8.0.2, but I don't recall such issue with 8.0.2. I restarted it few times yesterday, before I flashed 8.1, and it was quick.
It could be something else of course, but I don't recall any other changes when moved from 8.0.2 to 8.1

@antst
Copy link

antst commented Jan 8, 2025

OK, I am lost :)
tried few more restarts of z2m. startup time varies quite a lot in range 1:45 to 6:00,

[2025-01-08 15:47:50] info: 	z2m:mqtt: MQTT publish: topic 'zigbee2mqtt/bridge/state', payload '{"state":"online"}'
[2025-01-08 15:53:31] info: 	z2m: Started frontend on port 8099

It is not, for sure, mqtt, as after connection it sends to MQTT something immediately.
But during this time, z2m does not respond to any mqtt payloads and does not report anything also.

@antst
Copy link

antst commented Jan 8, 2025

Just in case, I tried yours 115200 FW and mine 460800 and 921600. No difference.
Starting with debug enabled didn't help that much either :)
same for strace.
ATM I will not dive into it, let see if there are more reports of similar here or in Z2M (as I it is not necessary confirmed to be FW problem so far)

@Nerivec
Copy link
Owner Author

Nerivec commented Jan 8, 2025

Can you confirm it still happens with 8.0.2? 8.1.0 definitely has issues.
If yes, can you check the timings in the logs? I had noticed an issue in some report logs before where, when a device (or several) hammers the network as soon as NETWORK_UP is triggered, Z2M (NodeJS?) appears to have a hard time with it for some reason, and since NETWORK_UP happens some time before Z2M is fully started, that can lengthen the startup time (which should only take a few seconds in normal circumstances...).
Here's an example on my live network:

[2024-10-30 20:35:22] info: 	z2m: Logging to console, file (filename: log.log)
...
[2024-10-30 20:35:26] info: 	z2m: Started frontend on port 8099
[2024-10-30 20:35:26] info: 	z2m: Zigbee2MQTT started!

(I know timestamps are pretty old, I've been testing long-term stability in longer increments since ember release... that's the last time I restarted Z2M. Gonna have to end that experiment soon though, 2.0.0 is calling 😜)

PS: you can find me on Discord if needed!

@antst
Copy link

antst commented Jan 8, 2025

@Nerivec
I'll try now with 8.0.2 to recheck. Maybe my memory bad :)

@antst
Copy link

antst commented Jan 8, 2025

OK, tried 8.0.2. Same problem, apparently. So it is not 8.1 issue.
Now I am confused. I never seen it with ZBDongle-E, but.... those observations were with 1.4.x. With 2.0 I used ZBDongle only for 4 days and restarted only once and didn't pay attention as was busy with something else.
So, this problem started with either Z2M 2.0 or with switch to 07mg24.

Damn, next logical step is to put back zbdongle and check it with that one. But I have now feeling that this is Z2M regression.

timings from Z2M 2.0 with 07mg24 with 8.0.2 firmware:

[2025-01-08 17:27:27] info: 	z2m: Connected to MQTT server
...
[2025-01-08 17:34:03] info: 	z2m: Started frontend on port 8099

@antst
Copy link

antst commented Jan 8, 2025

I checked also with debug log level.
this time is busy with processing incoming zigbee messages, but I can't say that there are thousands of them. 3-10 per second. And network is still the same as used to be with 1.4.2, when start time was like couple seconds.
I'd imagine that something is changed in incoming message handler. or around it. or maybe it tries to do something , which is impossible to do before full start and timeouts, or there is some blocking.
But I doubt that 3-10 messages a second can not be processed faster, and they were in 1.4.2

@antst
Copy link

antst commented Jan 8, 2025

@Nerivec
Made issue in Z2M, as I think it belongs there
Koenkk/zigbee2mqtt#25681

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants