Zigbee raspberry pi serial

Hi,
do i have to activate the serial interface manually somehow?
nymea say ‘Thing is not connected’ at /dev/ttyAMA0
Hardware is deCONZ plugged into the GPIO Pins.

I found out that i can connect via ssh to enable it via ‘sudo raspi-config’ > Interfacing Options > Serial.

But nymea:app still shows the message above.
Maybe it is because the dongle is the RaspBee first generation, not RaspBee II.

Some Debug output:

I | Zigbee: Found serial port “ttyAMA0”
I | Zigbee: Description: “”
I | Zigbee: System location: “/dev/ttyAMA0”
I | Zigbee: Manufacturer: “”
I | Zigbee: Serialnumber: “”
I | Zigbee: Using baudrate param QVariant(int, 38400)
I | Zigbee: Found serial port “ttyS0”
I | Zigbee: Description: “”
I | Zigbee: System location: “/dev/ttyS0”
I | Zigbee: Manufacturer: “”
I | Zigbee: Serialnumber: “”
I | Zigbee: Using baudrate param QVariant(int, 38400)

more output:
nymea@nymea:~ $ dmesg | grep S0
[ 2.602516] 3f215040.serial: ttyS0 at MMIO 0x0 (irq = 53, base_baud = 50000000) is a 16550
nymea@nymea:~ $ dmesg | grep Serial
[ 0.049996] Serial: AMBA PL011 UART driver
[ 1.437204] Serial: 8250/16550 driver, 1 ports, IRQ sharing enabled
[ 2.491854] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[ 2.499081] usb usb1: SerialNumber: 3f980000.usb
[ 3.181345] usb 1-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[ 3.642210] usb 1-1.1: New USB device strings: Mfr=0, Product=0, SerialNumber=0

Hmm, interesting, so the ConBee 1 worked for me (USB version), but not for @mzanetti. Need to check what might be the issue there. If you are using the GPIO RaspBee II, you need to enable the serial login and disable the tty on that UART of the Pi. You can find those instructions here: https://phoscon.de/en/raspbee2/install#raspbian
The RTC stuff is optional, but helpfull :slight_smile:

If you are using the GPIO UART, the controller will be the ttyS0, any you need to use Baudrate 38400.

Please note: the entire zigbee stack within nymea is currently under heavy construction, there is gonna change a lot in the near future! It’s gonna be better :slight_smile:

I am using GPIO RaspBee I on ttyS0 but still not connected.
Serial is enabled via raspi-config as written in the manual.

Shell for that also disabled? I was searching quiet some time until I found out that you need to disable the tty on that serial.

Yes, shell is disabled.

And i have it successfully running on OpenHAB (in an extra RaspPi). So the hardware is OK.

Is there any additional nymea output if you try to set up ttyS0? I have no RaspBee I for GPIO, only the USB version. Maybe that gives me a hint what’s going on.

Only this log:

I | Zigbee: Found serial port “ttyAMA0”
I | Zigbee: Description: “”
I | Zigbee: System location: “/dev/ttyAMA0”
I | Zigbee: Manufacturer: “”
I | Zigbee: Serialnumber: “”
I | Zigbee: Using baudrate param QVariant(int, 38400)
I | Zigbee: Found serial port “ttyS0”
I | Zigbee: Description: “”
I | Zigbee: System location: “/dev/ttyS0”
I | Zigbee: Manufacturer: “”
I | Zigbee: Serialnumber: “”
I | Zigbee: Using baudrate param QVariant(int, 38400)

And and that it timed out.
I just enabled the Zigbee log level.

You have this document? https://deconz.dresden-elektronik.de/raspbian/deCONZ-Serial-Protocol-en_1.14.pdf?ref=gh

Do you start the setup for the Zigbee Controller?

So here is how this works: the plugin checks if there is any UART device which is well known and provides information from the USB module (like manufacturer, vendor and serialnumber). If the device is known (currently only ConBee II USB stick and NXP stick), it autostarts the setup for the controller. If you have a raw UART device (like the GPIO one), those information can not be provided, and the plugin can not know if this is a ZigBee Controller.

In that case, since we know there is a Zigbee Controller connected to ttyS0, you need to run the setup manually.

yeah, the conbee backend is based on this document :slight_smile:

I did setup the new Thing manually.

The Plugin has no debug output regarding the serial connection/communication?
And what error is really happening.


A little bit more log:

When i hit the ‘Factory Reset Network’ button —

W | ZigbeeNetwork: Hardware controller is not available any more.
I | Zigbee: Controller state changed ZigbeeNetwork::StateOffline Thing(“zigbee”, id: “{1bf919fd-d057-4c79-a14c-d8b5f5d5a73f}”, ThingClassId: “{ff29c3c5-9f0f-4a04-9cf6-aef34928d781}”)
I | Zigbee: Controller state changed ZigbeeNetwork::StateUninitialized Thing(“zigbee”, id: “{1bf919fd-d057-4c79-a14c-d8b5f5d5a73f}”, ThingClassId: “{ff29c3c5-9f0f-4a04-9cf6-aef34928d781}”)
I | Zigbee: Controller state changed ZigbeeNetwork::StateStarting Thing(“zigbee”, id: “{1bf919fd-d057-4c79-a14c-d8b5f5d5a73f}”, ThingClassId: “{ff29c3c5-9f0f-4a04-9cf6-aef34928d781}”)
W | ZigbeeController: Reply timeout InterfaceReply(“Request controller version”, 0)
W | ZigbeeController: Request Deconz::CommandVersion finished with error Deconz::StatusCodeError

It looks like the device is not responding at all. The very first request (firmware version) is time-outing, indicating he does not get any response…

There are many debug categories for the entire ZigBee stack, for example you could start nymea with following command, and you see all information down to the actual bytes transmitted to the controller:

sudo QT_LOGGING_RULES=\
"*.debug=false;"\
"Zigbee.debug=true;"\
"ZigbeeAps.debug=false;"\
"ZigbeeNetwork.debug=true;"\
"ZigbeeNode.debug=false;"\
"ZigbeeCluster.debug=false;"\
"ZigbeeController.debug=true;"\
"ZigbeeInterface.debug=true;"\
"ZigbeeInterfaceTraffic.debug=true;" 
nymead -n

Note: they are within the library, that’s why you cannot enable them using the debug interface. You cann add those lines also into the nymead.conf LogginCategory section.

This should give much more information on whats going on, but from you logs the device simply does not respond.

I found this document: https://cdn-reichelt.de/documents/datenblatt/R800/RASPBEE-BHB-EN.pdf

Not sure how up to date it is regarding the uart, but there is also a reset pin. Is your controller blinking or something? Normally reset pins need to be defaulted to 1. Sadly I cannot test it my self.

I also don’t know yet for what the GPIO is.

Thank you for this, now i have more output for you:

I | Zigbee: Setup device “zigbee” ParamList (count:3)
0: Param(Id: “{c27df339-43c2-4b14-8bd8-aa051716e5d8}”, Value:QVariant(QString, “/dev/ttyS0”))
1: Param(Id: “{0a7ef4de-6d82-42d4-b56f-1e7ffc06e9f8}”, Value:QVariant(uint, 38400))
2: Param(Id: “{9a31274c-4511-425b-ad5a-f970b8a5b334}”, Value:QVariant(QString, “deCONZ”))
I | Zigbee: Create zigbee network manager for controller Thing(“zigbee”, id: “{1bf919fd-d057-4c79-a14c-d8b5f5d5a73f}”, ThingClassId: “{ff29c3c5-9f0f-4a04-9cf6-aef34928d781}”)
I | ZigbeeNetwork: Load current network configuration from “/etc/nymea/nymea-zigbee.conf”
I | ZigbeeInterface: Start UART interface “/dev/ttyS0” 38400
I | ZigbeeInterface: Interface enabled successfully on “/dev/ttyS0” 38400
I | ZigbeeController: Interface available changed true
I | ZigbeeController: Available changed true
I | ZigbeeNetwork: State changed ZigbeeNetwork::StateStarting
I | Zigbee: Controller state changed ZigbeeNetwork::StateStarting Thing(“zigbee”, id: “{1bf919fd-d057-4c79-a14c-d8b5f5d5a73f}”, ThingClassId: “{ff29c3c5-9f0f-4a04-9cf6-aef34928d781}”)
I | ZigbeeNetwork: Hardware controller is now available.
I | ZigbeeNetwork: Start zigbee network internally
I | ZigbeeNetwork: Reading current firmware version…
I | ZigbeeController: Enqueue request: “Request controller version”
I | ZigbeeController: Send request InterfaceReply(“Request controller version”, 0)
I | ZigbeeInterface: Send frame “0x0d 0x00 0x00 0x05 0x00 0xee 0xff”
I | ZigbeeInterfaceTraffic: --> “0xc0 0x0d 0x00 0x00 0x05 0x00 0xee 0xff 0xc0”
W | Tado: Not sending request, get the access token first
I | Zigbee: Post setup device “zigbee” ParamList (count:3)
0: Param(Id: “{c27df339-43c2-4b14-8bd8-aa051716e5d8}”, Value:QVariant(QString, “/dev/ttyS0”))
1: Param(Id: “{0a7ef4de-6d82-42d4-b56f-1e7ffc06e9f8}”, Value:QVariant(uint, 38400))
2: Param(Id: “{9a31274c-4511-425b-ad5a-f970b8a5b334}”, Value:QVariant(QString, “deCONZ”))
W | Kodi: got error response for request “Player.GetProperties” : “Invalid params.”
W | Kodi: got error response for request “Player.GetItem” : “Invalid params.”
W | ZigbeeController: Reply timeout InterfaceReply(“Request controller version”, 0)
W | ZigbeeController: Request Deconz::CommandVersion finished with error Deconz::StatusCodeError

Indeed, the controller simply does not respond to the request at all. According to the document the Bluetooth TTY has to be disabled and then the AMA0 needs to be used. I’m not sure why, but this hardware was initially built for raspberry pi without bluetooth (1, 2) I guess.

Worth a try; disable the Bluetooth UART and re-set up the ZigBee Controller with the AMA0 UART. (Chapter 4.4)

Are the LED’s from the controller blinking somehow? That would tell us if the reset pin is as it should be.

On the controller only one steady red light is lit.
No blinking of the green one (as it is normally when in the other raspberry with deCONZ directly)

I waited a little longer now and got some interresting output:

I | Zigbee: Executing action for device “zigbee” “{d6153a98-f1a8-4bc4-a1d7-6f986886bf46}” ParamList (count:0)

W | Tplink: Error in device connection: QAbstractSocket::RemoteHostClosedError
I | ZigbeeInterfaceTraffic: <-- “0x1c 0x06 0x00 0x0c 0x00 0x05 0x00 0x02 0x8f 0xaf 0xc7 0xbe 0x08 0xfd”
I | ZigbeeInterface: Received frame “0x1c 0x06 0x00 0x0c 0x00 0x05 0x00 0x02 0x8f 0xaf 0xc7 0xbe 0x08 0xfd”
I | ZigbeeController: Interface message received Deconz::CommandMacPoll SQN: 6 Deconz::StatusCodeSuccess Frame length: 12 “0x05 0x00 0x02 0x8f 0xaf 0xc7 0xbe”
I | ZigbeeController: MAC Poll command received “0x05 0x00 0x02 0x8f 0xaf 0xc7 0xbe”

It’s alive! Was it the ttyAMA0? Now you are getting data (MAC Poll messages, which is not very clear to me what they are for, and not documented at all during the state of development).

Try now to perform a factory reset, which should start the network from scratch and perform the entire startup sequence.In theory, it should work now, unless I have a protocol missmatch due to an old firmware version, but I covered the API changes from 1.08 and higher.

I’d appreciate if you guys could write down some notes on what exactly a user has to do to set up this particular hardware so we can create good tutorials when the zigbee stuff is going to be released.

You know what?

I disabled the f bluetooth and it works!!!*

(maybe there is a difference in RPI3 B and B+ as on the B+ and deCONZ i had not problems)

:vulcan_salute: nice!

As mentioned, we are making the zigbee stuff in a propery way currently, so expect many updates in the near future.

Our plan is to integrate the zigbee network management directly into the nymea stack, and distribute the support for different zigbee devices to different plugins. For now, everything is in the plugin for test purposes and get a feeling for the technology.

If you have devices which are not supported yet (I guess there are many), please feel free to post the logs before the the warning: W | Zigbee: Could not create a device for this node. Please send the cluster node information to nymea, maybe we can change this :). Logs before this warning give information about the device and it will be quiet easy in the near future to implement unsupported devices. Stuff like lights are already covered in a generic way :slight_smile:

Remote controllers need a bit more attention once the stack is built into nymea, since they require group bindings in order to get button notifications.

1 Like