dresden-elektronik / deconz-serial-protocol

deCONZ Serial Protocol
7 stars 2 forks source link

No reception of data #16

Open pwielders opened 2 years ago

pwielders commented 2 years ago

All initializations seems to succeed on the RPI (Raspbee) Panid = 0xDEAF, Channel 15. All configuration succeeds over the serial port, log below but it looks like I do not receive any messages from the radio (from other devices). I am writing the serial interface in the context of the RDK stack (so from scratch, using your documentation here) and with the USB stick (CONBEE) the same code works fine (it does receive data from other nodes). Could it be that for the Raspbee I need to enable the SW1 pin [11] for the radio to turn on ? Or do I need to move the reset pin [12] to an output (I assume that due to the fact that by default it is an input, it is sufficient).

Log of the intialization: Jan 1 00:00:04 buildroot user.notice /usr/bin/bridge[212]: [00:00:04]: Send: 0D:01:00:09:00:00:00:00:00:E9:FF
Jan 1 00:00:04 buildroot user.notice /usr/bin/bridge[212]: [00:00:04]: Received: 0D:01:00:09:00:00:05:39:26
Jan 1 00:00:04 buildroot user.notice /usr/bin/bridge[212]: [00:00:04]: Metadata: Version: 38.57 Platform: "Conbee"
Jan 1 00:00:04 buildroot user.notice /usr/bin/bridge[212]: [00:00:04]: Send: 0A:02:00:08:00:01:00:01:EA:FF
Jan 1 00:00:04 buildroot user.notice /usr/bin/bridge[212]: [00:00:04]: Received: 0A:02:00:10:00:09:00:01:E7:41:01:FF:FF:2E:21:00
Jan 1 00:00:04 buildroot user.notice /usr/bin/bridge[212]: [00:00:04]: Read: Parameter "MAC Address"
Jan 1 00:00:04 buildroot user.notice /usr/bin/bridge[212]: [00:00:04]: Send: 0A:03:00:08:00:01:00:07:E3:FF
Jan 1 00:00:04 buildroot user.notice /usr/bin/bridge[212]: [00:00:04]: Received: 0A:03:00:0A:00:03:00:07:00:00
Jan 1 00:00:04 buildroot user.notice /usr/bin/bridge[212]: [00:00:04]: Read: Parameter "Network address"
Jan 1 00:00:04 buildroot user.notice /usr/bin/bridge[212]: [00:00:04]: Send: 0A:04:00:08:00:01:00:09:E0:FF
Jan 1 00:00:04 buildroot user.notice /usr/bin/bridge[212]: [00:00:04]: Received: 0A:04:00:09:00:02:00:09:01
Jan 1 00:00:04 buildroot user.notice /usr/bin/bridge[212]: [00:00:04]: Read: Parameter "APS Designed mode"
Jan 1 00:00:04 buildroot user.notice /usr/bin/bridge[212]: [00:00:04]: Send: 0A:05:00:08:00:01:00:22:C6:FF
Jan 1 00:00:04 buildroot user.notice /usr/bin/bridge[212]: [00:00:04]: Received: 0A:05:00:0A:00:03:00:22:0C:01
Jan 1 00:00:04 buildroot user.notice /usr/bin/bridge[212]: [00:00:04]: Read: Parameter "Protocol version"
Jan 1 00:00:04 buildroot user.notice /usr/bin/bridge[212]: [00:00:04]: Send: 0A:06:00:08:00:01:00:05:E2:FF
Jan 1 00:00:04 buildroot user.notice /usr/bin/bridge[212]: [00:00:04]: Received: 0A:06:00:0A:00:03:00:05:AF:DE
Jan 1 00:00:04 buildroot user.notice /usr/bin/bridge[212]: [00:00:04]: Read: Parameter "Network PAN Id"
Jan 1 00:00:04 buildroot user.notice /usr/bin/bridge[212]: [00:00:04]: Send: 0A:07:00:08:00:01:00:0A:DC:FF
Jan 1 00:00:04 buildroot user.notice /usr/bin/bridge[212]: [00:00:04]: Received: 0A:07:00:0C:00:05:00:0A:00:80:00:00
Jan 1 00:00:04 buildroot user.notice /usr/bin/bridge[212]: [00:00:04]: Read: Parameter "Channel mask"
Jan 1 00:00:04 buildroot user.notice /usr/bin/bridge[212]: [00:00:04]: Send: 0A:08:00:08:00:01:00:26:BF:FF
Jan 1 00:00:04 buildroot user.notice /usr/bin/bridge[212]: [00:00:04]: Received: 0A:08:00:0C:00:05:00:26:94:0D:00:00
Jan 1 00:00:04 buildroot user.notice /usr/bin/bridge[212]: [00:00:04]: Read: Parameter "Watchdog"
Jan 1 00:00:04 buildroot user.notice /usr/bin/bridge[212]: [00:00:04]: Send: 0B:09:00:0C:00:05:00:26:88:0E:00:00:1F:FF
Jan 1 00:00:04 buildroot user.notice /usr/bin/bridge[212]: [00:00:04]: Received: 0B:09:00:08:00:01:00:26
Jan 1 00:00:04 buildroot user.notice /usr/bin/bridge[212]: [00:00:04]: Write: Parameter "Watchdog"
Jan 1 00:00:04 buildroot user.notice /usr/bin/bridge[212]: [00:00:04]: Watchdog @ [3476] loaded with [3720] seconds, Reset @ [Thu, 01 Jan 1970 01:00:04 GMT]

pwielders commented 2 years ago

Continued the investigation and I think I should send a Create or Join Network Request (Chapter 7.2) It seems this is not needed for the USB dongle (CONBEE) but seems to be necessary (and logical) for the Serial RASPBEE. However, if I send it I do net get an error but it also dos not move to connected.

This is what I am sending: [Wed, 05 Jan 2022 14:32:39]:[Dresden.cpp:745] DataFrame: Send: 08:0A:00:06:00:02:E6:FF [Wed, 05 Jan 2022 14:32:39]:[Dresden.cpp:761] DataFrame: Received: 08:0A:00:06:00:00

I am using NET_CONNECTED (0x02) as the manual depicts but the Role is Controller, should I maybe use NET_JOINING ?

pwielders commented 2 years ago

Nope NET_JOINING reports invalid parameter :-) I also do not observe any flickering on the transmit led.. If I run the deconz software it works proeprly... So there must be something that I need to do to turn on the radio to enable it. Again, using the CONBEE with the same setup and the same software (both are plugged in) works fine :-)

manup commented 2 years ago

Basically for the network disconnect + connect is needed in case of a reconfiguration of the network parameters. If I parse the above messages correctly the parameters look ok, however in order for the network to work correctly also the following need to have valid values:

Could it be that these aren't set yet or have invalid values?

The firmware for ConBee 1 and RaspBee 1 is the same so there shouldn't be differences on the protocol level, I'd assume that on the RaspBee the configuration is not valid for some reason.

pwielders commented 2 years ago

Thanks for the feedback and in the meantime I kept on experimenting and I am embarrassed to say but it was working the whole time ;-) The issue was that I had been experimenting with the CONBEE and thus there where already all kind of devices hooked up to it where I was assuming that even with a new device I would see some form of BEACON popping up or message flying by. Probably I did not wait long enough cause I now first started pairing some devices to the RASPBEE as well and then I did receive messages. So sorry for raising this while I did not properly analyse it :-(

On second thought I think this is where my misunderstanding started: I thought that if I would set the PANId of the RASPBEE controller to the same PANId as the CONBEE, I should be able to see the devices that where already in the PANId formed by the CONBEE network with that PANId. However, giving this more thought I guess, and probably need to read the theory, this is a wrong assumption as the communication involves the MAC for the destination (CONBEE Controller) and thus will never endup on the RASPBEE controller although it was in the same network (with Adddress 0x0000 but different MAC)

So sorry for wasting your time, but I do have now a full working setup using RASPBEE and CONBEE, time to focus on the end devices !!!

Thasnk for all the support and we can close this ticket.

pwielders commented 2 years ago

HOwever, one more question (more for me to know) What is the SW1 pin on the GPIO port doing? Where can I use it for. Is it an input to the RASPBEE, and I can turn something on in the device if I would control it and set it to 1 or 0? or should I observe that pin and the RASPBEE device will signal something to me ?