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

8024: Status: 04: Busy Node #74

Open
pipiche38 opened this issue Nov 9, 2018 · 15 comments

Comments

@pipiche38
Copy link

commented Nov 9, 2018

When sending command 0x0024 , I'm getting in return 0x8024 with a Status != 0

Status: 0x04

However the system seems to behave correctly !

Here after is my startup phase:

0x0010
0x0009
0x0015
0x0021 on channel 11
0x0023
0x0024
0x0040 ( optional )

@pipiche38

This comment has been minimized.

Copy link
Author

commented Nov 9, 2018

Not an issue Status Code 04 is Busy Node

@pipiche38 pipiche38 closed this Nov 9, 2018

@doudz

This comment has been minimized.

Copy link
Contributor

commented Nov 16, 2018

I'm facing the same problem, how do you handle it ? (status 4)

@pipiche38 pipiche38 reopened this Nov 16, 2018

@pipiche38 pipiche38 changed the title 8024: Status: 04: Fragmented data requests must be sent with APS ack (fatal error) 8024: Status: 04: Busy Node Nov 16, 2018

@pipiche38

This comment has been minimized.

Copy link
Author

commented Nov 16, 2018

@doudz I re-open the case and update the title.
So far I'm not handling ;-)

But what I found is that I'm receiving less data than expected. Basically the message is shorter than the 24bytes expected.

@doudz

This comment has been minimized.

Copy link
Contributor

commented Nov 16, 2018

I think it means that the network is already started so not forming a new one, not joining, so start_network could not be done since it's already done
But the response doesn't respect the doc since there's no short addr, no ieee addr and no channel

In previous firmware (3.0d) the command 0x0024 just return nothing
#15

@pipiche38

This comment has been minimized.

Copy link
Author

commented Nov 16, 2018

Sébastien , while looking quickly at the source code, it looks like indeed it refers to a new network created after Reset. This is why also in my initial issue I put the sequence of command when starting as I suspect that some commands are not necessary needed when in steady state (outside of Software Reset, erase PDM ..), but hard to find the right start sequence.

@doudz

This comment has been minimized.

Copy link
Contributor

commented Nov 16, 2018

Ok, so the busy status 4 should be safely ignore since it's not an error.

@pipiche38

This comment has been minimized.

Copy link
Author

commented Nov 16, 2018

This is my view right now, but still I think that if we can figure out what is the proper startup sequence we would be better .

Here is what I've got from @akila once :

Les commandes :
Set channel
Set type coordinator
Start network

ne doivent être lancée qu'une fois après une initialisation (erase PDM).
Les lancer à chaque fois peut créer des problèmes."

@KiwiHC16

This comment has been minimized.

Copy link

commented Nov 16, 2018

A start network is enough.
Coordinator is by default.
Set Channel is up to you to decide, otherwise will take the less noisy channel.

@ISO-B

This comment has been minimized.

Copy link
Collaborator

commented Mar 6, 2019

There is 4 possible status codes to get from 8024:

id Description
0x00 Success
0x02 Error invalid parameter. If End device tries to form network. Should not be possible with ZiGate as it is Coordinator
0x04 Node is on network. ZiGate is already in network so network is already format
0x06 Commissioning in progress. If network forming is already in progress

Success message comes when network formation success event is triggered. There is also event for network formation failure, but it doesn't send any feedback for user.

When ZiGate starts after with empty pdm it won't be part of any network. Sending 0x0024 will try to form network. That is straight forward case.

After Zigate starts with network details in pdm it will send same 8024 response as when it has formed network. This happens very quickly after startup so if you miss this you don't know that network is already formed. If you now send 0x0024 it will try forming network again, which should fail with code 0x04. Would it be desired to get same 24bytes long response that ZiGate sends at startup, but with status code 0x04?

@ISO-B ISO-B added the enhancement label Mar 6, 2019

@pipiche38

This comment has been minimized.

Copy link
Author

commented Mar 6, 2019

Would it be desired to get same 24bytes long response that ZiGate sends at startup, but with status code 0x04?

I would tend to say that it makes sense.

@KiwiHC16 , @doudz what do you think ?

@doudz

This comment has been minimized.

Copy link
Contributor

commented Mar 6, 2019

@pipiche38 I don't understand your difficulties with 0x8024... sorry

@pipiche38

This comment has been minimized.

Copy link
Author

commented Mar 6, 2019

@doudz you were mentioning having the same problem #74 (comment)

What @ISO-B is proposing seems to be logical, just wanted to check if you are also fine with that

@doudz

This comment has been minimized.

Copy link
Contributor

commented Mar 6, 2019

@pipiche38 but as I said : Ok, so the busy status 4 should be safely ignore since it's not an error.

@pipiche38

This comment has been minimized.

Copy link
Author

commented Mar 6, 2019

Fine with me, but then let's get the documentation updated, or get the fix proposed by @ISO-B

@ISO-B

This comment has been minimized.

Copy link
Collaborator

commented Mar 22, 2019

@fairecasoimeme can you add status 0x04 (Node is on network. ZiGate is already in network so network is already format) for this commands documentation.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
4 participants
You can’t perform that action at this time.