Implement new zigpy network state #445
Conversation
|
@puddly in the __init __() of ControllerApplication could you call SCHEMA(config) in the super().__init __() like other libs ? |
|
This has been fixed inside of zigpy itself: puddly/zigpy@4c78afc |
|
@puddly I tried the new load_network_info function and I don't know what to think about the result:
do you have the same with your controller ? |
|
That mostly matches what I see with my coordinator but since I don't normally use a SiLabs coordinator, I'm not sure if it's "normal" or not. None of that information is critical, it was just included to make the ZNP backup complete. |
|
It's not critical but it's something we use in the initialization part to check if the couple IEEE/shortId is still up-to-date.
|
It is not critical, but it is quiet important. The main reason is that if you have your coordinator working, but you have your application/box/plugin off ( maintenance, upgrade ....), when restarting the plugin it is a really great things to be able to load Ieee/Nwkid and check against the last plugin state and eventually update it. In zigpy I believe device database is updated accordingly. |
|
Just made some test live:
|
When a RSTACK message is processed right after the UART has been opened, it causes EZSP.enter_failed_state() getting called at a point where the application callbacks are not registered yet. In that case the UART will get closed and it won't get opened again. Bellows is stuck with a closed transport. Avoid this issue by not closing the port in case there is no application callback registered yet. Typically, it is unlikely that a RSTACK message arrives right when the port gets opened (the race window is very narrow). However, with hardware flow control opening the port leads to RTS signal to get asserted which causes the radio to send pending messages, e.g. resets caused by EmberZNet watchdog. Note: With hardware flow control this is only the case if the tty "hupcl" option is set. The option is set by default, but cleared by tools like GNU screen. This option makes sure that the RTS signal is deasserted while the port is closed. Pyserial/bellows does not change the state of that option.
|
@puddly , I'm trying to test the bellows new-radio-API ,and I'm current getting issue when importing. I'm using your branch puddly:puddly/zigpy-radio-api |
|
I don't think you're using the correct branch. |
|
Ok. I’ll wait for the merge
Envoyé de mon iPhone
… Le 20 juin 2022 à 22:16, puddly ***@***.***> a écrit :
I don't think you're using the correct branch. NetworkInformation does not appear in the source code.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
|
|
would it be possible to get this PR approved and merged ? We are waiting for it in order to integrate the full new-radio-API ( zigpy , zigpy-znp, zigpy-deconz ) have already been merged thanks in advance and thanks to @puddly for making it, this really make the usage across radio lib simpler |
|
gentlemen @Hedda, @puddly , @Adminiuga any chance to get this approve and merged ? Thanks in advance |
zigpy/zigpy#848
At the moment this PR is very WIP and I'm not very familiar with EZSP so there are likely mistakes with the hashed TCLK stuff. No unit tests pass and I've only tested it with zigpy-cli, though it does generate a valid backup for me.Test coverage is 100% 🎉