Virtual Serialport / Zigbee Router with CC2530

[mar565]

Is there already a way to connect the CC2530 directly and use it as a Zigbee Router?
There is already a solution with ESP-Easy but I would like to use it with a Sonoff basic running Tasmota:

http://www.zigbee2mqtt.io/how_tos/how_to_esp8266_with_cc2530.html

[ascillato2]

Hi,

There is no support for that zigbee chip at this moment, but a serial bridge to mqtt feature is already supported in Tasmota. So everything that comes from the serial port can be sent to mqtt and viceversa. If you need Tasmota to manage the initiallation of the chip, you can do it by using Tasmota rules feature, or by commands from mqtt to serial.

If you want to develop a driver for that chip, you can fork Tasmota and make a pull request. Help is always welcome.

Remember that it is available also the Tasmota Support Chat for helping you.

Thanks

---

Contributing Guideline and Policy
Support Guide.

Support Information

See Wiki for more information.
See FAQ for common questions/answers and links if none of your question is in the list
See Chat for more user experience.
See Community for forum.
See Code of Conduct

[s-hadinger]

I'm interested in this feature too. Zibgee2MQTT is too big to run on ESP8266, so having a Serial to MQTT would solve nicely this issue. I need to order my CC2530 first.

[meingraham]

@s-hadinger

@phiten has been working on a Tasmota2Zigbee bridge. He's selected the hardware and has the conceptual architecture for how it would work. He has been looking for some programming help. Please reach out to him. I think this project would fill a huge gap for Tasmota users!

Mike

[s-hadinger]

Thanks, I just ordered my CC2531. The short term solution would be indeed to send all Zigbee traffic to MQTT. It will require a small change in serial part to correctly detect end of frames.

I'm not sure whether we can use Zigbee directly from Tasmota. I also found another open-source lib much lighter than Zibgee2MQTT: https://github.com/Frans-Willem/AqaraHub

Stay tuned.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[arendst]

Work in progress

[s-hadinger]

See #6199 for a first step of Zigbee support. It will transfer to and from Mqtt any low-level frame to cc2530.

It's not really usable right now, it's an intermediate milestone to ease further development.

I don't think you can directly use Zigbee2Mqtt with this although adding an Mqtt bridge to it might be doable. I have plans for direct support at Tasmota level.

[tyjtyj]

@arendst is this still work in progress ? I bought the hardware, waiting for tasmota only..

[s-hadinger]

Yes it's progressing well. I hope to submit a new PR in the following days. You can start flashing cc2530 with instructions from here : https://github.com/s-hadinger/CCLib

Or use another way. Just stick to ZNP 1.2 default mode for coordinator.

[tyjtyj]

@s-hadinger, do I need to flash tasmota to wemo d1 before flashing cc2530? I got wemo d1 hardware and has not done anything on it yet

[tyjtyj]

So if my understanding is correct
(first time getting wemo d1)

1. flash wemo d1 with tasmota. Eg com7 on windows.
2. Connect cc2530 to wemo d1 and wemo d1 to pc USB. COM7 appear again
3. Run python Python/cc_info.py -p Com7
4. If above command correct found cc2530 , flash it.

I wondering if step 1 is necessary?

[s-hadinger]

Sorry for the confusion. You actually need the CCLib variant firmware to flash the CC2530. Once the CC2530 is flashed, then you can use Tasmota

[tyjtyj]

So for step 1, I need to flash wemo with cclib proxy.ino?
Can u update the Readme abit or how should I prepare my wemo d1 to flash cc2530.
I hv pi, can I flash cc2530 the same way flashing cc2531?
I appreciate all the help.

[s-hadinger]

I checked the CCLib repo, and it was missing some files.

Step 1: git clone https://github.com/s-hadinger/CCLib.git or git pull to update latest version.
Step 2: flash Wemos D1 mini with Bin/CCLib_proxy.ino.bin
Step 3: check connection python Python/cc_info.py -p <serial_port>
Step 4: flash python Python/cc_write_flash.py -e -p <serial_port> -i Bin/CC2530_DEFAULT_20190608_CC2530ZNP-Prod.hex

It takes ~60 minutes to flash, I will try to make it faster.

[tyjtyj]

Here is what I did

1. Connect Wemo D1 via USB(Found COM7) detected as USB-Serial-CH340, use nodeMCU flasher flash Bin/CCLib_proxy.ino.bin
2. Disconnect Wemo D1 from USB, Plug 3 cable of WEMO D1 - CC2530 and connect GPIO12-14 together.
3. Plug Wemo D1 via USB(Found COM7 again detected the same as above).
4. run
   python Python\cc_info.py -p COM7
   ERROR: No chip found. Check your connection and/or wiring!

which part did I go wrong ? I cross check the cable multiple times.

[tyjtyj]

I got different error after flashing WEMO second time.

python Python\cc_info.py -p COM7
ERROR: The chip is not responding. Check your connection and/or wiring!

I got it flashing...... Someone please plugging vcc and gnd for cc2530..

Thanks for all the help...

[tyjtyj]

So I got everything working

Try to get the data into home assistant. It appear that every time it post a data that does not have temperature. It will result home assistant capture blank. There is workaround to check the data using template but if you have lots of zigbee device this now longer feasible.

https://community.home-assistant.io/t/mqtt-publish-divided-values-to-same-topic/2236/11

sensor:
- platform: mqtt
  name: "ZigBee SQ Temperature"
  state_topic: "tele/zigbee/RESULT"
  value_template: '{{ value_json["0xC301"]["Temperature"] }}'
  availability_topic: "tele/zigbee/LWT"
  payload_available: "Online"
  payload_not_available: "Offline"
  unit_of_measurement: "°C" 

Can I suggest instead
04:19:34 MQT: tele/zigbee/RESULT = {"0xC301":{"Temperature":30.59}}
use this
04:19:34 MQT: tele/zigbee/RESULT/0xC301/Temperature = 30.59

[s-hadinger]

Good to hear you could make it work. As you are the first to follow these instructions, please report or directly fix the wiki if you found some information inaccurate or unclear.

I plan to work on improving the flashing process: first remove the need to short 2 GPIOs, second make it faster (it should normally go down to 3 minutes).

Good point on the MQTT format, that is a debate I want to open. Should we have a MQTT topic per device or a unique MQTT topic with device information in the JSON.

As for Home Assistant, there is no simple way to fix it. Zigbee2MQTT keeps track of all values of all devices to send them back - but them have unlimited disk storage. We don't have this luxury in Tasmota where Flash is very precious. An easy answer would be to fix HA, and let them have an option to maintain a sensor value to the previous measure if it's missing.

Still let me think about it, if we use Wemos D1 mini, we actually got 4MB Flash, so SPIFFS could be an option...

[meingraham]

My vote is that the data transmitted should follow the format used for any other Tasmota sensor. The question perhaps is whether it should be a RESULT or SENSOR message.

This allows the data to be used as Rules triggers as well: tele-0xC301#Temperature

tele/<topic>/SENSOR = {"0xC301":{"Temperature":30.59}}
tele/<topic>/SENSOR = {"ANALOG":{"Illuminance":1}}
tele/<topic>/SENSOR = {"ENERGY":{"TotalStartTime":"2018-12-10T17:32:10","Total":297.131,"Yesterday":0.000,"Today":0.001,"Period":0.00,"Power":0.00,"ApparentPower":0.00,"ReactivePower":0.00,"Factor":0.00,"Voltage":118.50,"Current":0.000}}

A home automation hub has the capability and capacity to handle these situations... even if it takes a bit of extra logic.

Using a special topic for each sensor (e.g., tele/zigbee/RESULT/0xC301/Temperature) would diverge from how Tasmota treats all other transmitted sensor messages.

[meingraham]

Also, @digiblur had a great recommendation for something similar involving an RF Bridge...

You could setup a rule to send all RFReceived data to a custom topic of your choice too.

In your case, you could set up a rule, triggered by the sensor message, to publish the Zigbee sensor data to a specific topic as you wish.

[tyjtyj]

I tried automation path, home assistant can't keep up with the data. I hv 16 power monitoring switch and hass can't keep up with energy data, some data missed. There are plenty of error 'script still running in the logs.'
Anyway, it should use'sensor instead of result like you mentioned.

@s-hadinger, ur step almost prefect. It just did not connect the 3.3v n ground to cc2530 resulting the chip not recognized. I will fix the wiki when I hv desktop with me. Again thanks for all the guide.
I'll let the bridge runs for few days to test its stability. Below is 1st time like for me

• first wemo flash cc proxy
• first zigbee controller
• first compile of tasmota dev.

[s-hadinger]

@tyjtyj Thanks for the feedback. I'm almost surprised everything worked well. This is good news.

@meingraham Good insights as always. I will keep it the way it is today, it's important to be consistent with Tasmota sensors. The only thing I may change is putting an alias to replace the address of the device, i.e. have Kitchen instead of 0xC301.

On the topic of missing values in HA, afterthoughts I think it is definitely a HA issue. HA should have an option to maintain a missing value to its previous known value. I prefer Zigbee/Tasmota code to be as neutral as possible: report back in MQTT the reading of the sensor, no more no less. If they are split in different Zigbee message, there will be different MQTT messages.

[meingraham]

I made some substantial edits to the wiki. Hopefully the entire process is accurate... and clearer now. I incorporated some feedback from the Discord mods.

[s-hadinger]

@tyjtyj Can you please type ZigbeeStatus 1 and report the modelId of your sensor ?

[tyjtyj]

05:11:35 CMD: ZigbeeStatus 1
05:11:35 MQT: stat/zigbee/RESULT = {"ZigbeeStatus1":[{"ShortAddr":"0xBC3F","IEEEAddr":"0000000000000000"}]}

[s-hadinger]

@tyjtyj Unfortunately it didn't capture the modelId. One way to get it is to force a re-pairing.

Can you please type ZigbeePermitJoin 1, press the button for 5 seconds, wait for a few seconds (you should see many messages), and ZigbeeStatus 1.

[tyjtyj]

Here you go

08:00:48 MQT: stat/zigbee/RESULT = {"ZigbeeStatus1":{"ShortAddr":"0xBC3F","IEEEAddr":"0000000000000000"},"ShortAddr":"0x0EB5","IEEEAddr":"00158D00036B4BDC","ModelId":"lumi.weather","Manufacturer":"LMI"},"ShortAddr":"0xF874","IEEEAddr":"00158D00041451AC","ModelId":"lumi.sensor_motion.aq2"}]}

I notice my temperature sensor change id after re-pair, it because version upgrade on tasmota or why the id changed ?

[s-hadinger]

Thanks you. It appears that the JSON above is broken. Was it the actual output?

The shortaddr is randomly assigned when pairing, and re-pairing. That's why I want to work on a friendly name based on longaddr which does not change, but is not sent systematically either.

I have one more request, can you please check whether the "Temperature" field (which is actually a boolan, so it should show either '0'-false or '0.01'-true) is correlated to the "Occupancy" value?

[tyjtyj]

let me just post again

19:53:32 MQT: stat/zigbee/RESULT = {"ZigbeeStatus1":[{"ShortAddr":"0xBC3F","IEEEAddr":"0000000000000000"},{"ShortAddr":"0x0EB5","IEEEAddr":"00158D00036B4BDC","ModelId":"lumi.weather","Manufacturer":"LUMI"},{"ShortAddr":"0xF874","IEEEAddr":"00158D00041451AC","ModelId":"lumi.sensor_motion.aq2"}]}

Occupancy is

19:53:03 MQT: tele/zigbee/RESULT = {"ZigbeeZNPReceived":"44810000060474F80101003F0020F95200000718C10A0000180174F81D"}
19:53:03 MQT: tele/zigbee/RESULT = {"ZigbeeZCLReceived":{"groupid":0,"clusterid":1030,"srcaddr":"0xF874","srcendpoint":1,"dstendpoint":1,"wasbroadcast":0,"linkquality":63,"securityuse":0,"seqnumber":0,"timestamp":5437728,"fc":"0x18","manuf":"0x0000","transact":193,"cmdid":"0x0A","payload":"00001801"}}
19:53:03 ZigbeeZCLRawReceived: {"0xF874":{"0406_0A_0000":1}}
19:53:03 MQT: tele/zigbee/RESULT = {"0xF874":{"Occupancy":1}}

Temperature

14:04:05 MQT: tele/zigbee/RESULT = {"ZigbeeZNPReceived":"448100000204B50E0101008800657A6800000818540A000029DD0AB50E1D"}
14:04:05 MQT: tele/zigbee/RESULT = {"ZigbeeZCLReceived":{"groupid":0,"clusterid":1026,"srcaddr":"0x0EB5","srcendpoint":1,"dstendpoint":1,"wasbroadcast":0,"linkquality":136,"securityuse":0,"seqnumber":0,"timestamp":6847077,"fc":"0x18","manuf":"0x0000","transact":84,"cmdid":"0x0A","payload":"000029DD0A"}}
14:04:05 ZigbeeZCLRawReceived: {"0x0EB5":{"0402_0A_0000":2781}}
14:04:05 MQT: tele/zigbee/RESULT = {"0x0EB5":{"Temperature":27.81}}
14:04:05 MQT: tele/zigbee/RESULT = {"ZigbeeZNPReceived":"448100000504B50E0101008800727A6800000818550A000021ED17B50E1D"}
14:04:05 MQT: tele/zigbee/RESULT = {"ZigbeeZCLReceived":{"groupid":0,"clusterid":1029,"srcaddr":"0x0EB5","srcendpoint":1,"dstendpoint":1,"wasbroadcast":0,"linkquality":136,"securityuse":0,"seqnumber":0,"timestamp":6847090,"fc":"0x18","manuf":"0x0000","transact":85,"cmdid":"0x0A","payload":"000021ED17"}}
14:04:05 ZigbeeZCLRawReceived: {"0x0EB5":{"0405_0A_0000":6125}}
14:04:05 MQT: tele/zigbee/RESULT = {"0x0EB5":{"Humidity":61.25}}
14:04:05 MQT: tele/zigbee/RESULT = {"ZigbeeZNPReceived":"448100000304B50E0101008B007C7A6800001118560A000029ED03140028FF1000294227B50E1D"}
14:04:05 MQT: tele/zigbee/RESULT = {"ZigbeeZCLReceived":{"groupid":0,"clusterid":1027,"srcaddr":"0x0EB5","srcendpoint":1,"dstendpoint":1,"wasbroadcast":0,"linkquality":139,"securityuse":0,"seqnumber":0,"timestamp":6847100,"fc":"0x18","manuf":"0x0000","transact":86,"cmdid":"0x0A","payload":"000029ED03140028FF1000294227"}}
14:04:05 ZigbeeZCLRawReceived: {"0x0EB5":{"0403_0A_0000":1005,"0403_0A_0014":-1,"0403_0A_0010":10050}}
14:04:05 MQT: tele/zigbee/RESULT = {"0x0EB5":{"PressureUnit":"hPa","Pressure":1005}}

[s-hadinger]

Thanks for posting logs.

Sorry, I meant the wrong "Temperature" reported for device 0xF874, like once per hour.

[tyjtyj]

I got what you mean by wrong temperature. I think it is xiaomi bug. it does not hv temperature sensor..

21:00:22 MQT: tele/zigbee/RESULT = {"ZigbeeZNPReceived":"44810000000074F8010100540015828C00002A1C5F11BE0A01FF422101210D0C03281E0421A8130521060006240D000000000A2100006410000B21190074F81D"}
21:00:22 MQT: tele/zigbee/RESULT = {"ZigbeeZCLReceived":{"groupid":0,"clusterid":0,"srcaddr":"0xF874","srcendpoint":1,"dstendpoint":1,"wasbroadcast":0,"linkquality":84,"securityuse":0,"seqnumber":0,"timestamp":9208341,"fc":"0x1C","manuf":"0x115F","transact":190,"cmdid":"0x0A","payload":"01FF422101210D0C03281E0421A8130521060006240D000000000A2100006410000B211900"}}
21:00:22 ZigbeeZCLRawReceived: {"0xF874":{"0000_0A_FF01":"01210D0C03281E0421A8130521060006240D000000000A2100006410000B211900"}}
21:00:22 MQT: tele/zigbee/RESULT = {"0xF874":{"Voltage":3.085,"Battery":100,"Temperature":0}}

can we have this already ?

tele/zigbee/RESULT = {"0x0EB5":{"PressureUnit":"hPa","Pressure":1005}}

to sensor ?

tele/zigbee/SENSOR = {"0x0EB5":{"PressureUnit":"hPa","Pressure":1005}}

i put up automation to parse the data to be usable by home assistant
https://github.com/tyjtyj/tasmota-zigbee-homeassistant/blob/master/README.md

[tyjtyj]

There is another issue .. .All the data receive by MQTT is double.
I turn on logging and here you can see it is duplicate once.

Message 291 received on tele/zigbee/RESULT at 2:20 PM:
{
    "ZigbeeZCLReceived": {
        "groupid": 0,
        "clusterid": 1024,
        "srcaddr": "0xF874",
        "srcendpoint": 1,
        "dstendpoint": 1,
        "wasbroadcast": 0,
        "linkquality": 89,
        "securityuse": 0,
        "seqnumber": 0,
        "timestamp": 1084164,
        "fc": "0x18",
        "manuf": "0x0000",
        "transact": 8,
        "cmdid": "0x0A",
        "payload": "0000210C00"
    }
}
QoS: 0 - Retain: false
Message 290 received on tele/zigbee/RESULT at 2:20 PM:
{
    "ZigbeeZCLReceived": {
        "groupid": 0,
        "clusterid": 1024,
        "srcaddr": "0xF874",
        "srcendpoint": 1,
        "dstendpoint": 1,
        "wasbroadcast": 0,
        "linkquality": 89,
        "securityuse": 0,
        "seqnumber": 0,
        "timestamp": 1084164,
        "fc": "0x18",
        "manuf": "0x0000",
        "transact": 8,
        "cmdid": "0x0A",
        "payload": "0000210C00"
    }
}
QoS: 0

[s-hadinger]

I will change from RESULT to SENSOR.

I didn't observe double MQTT message on my side. Did you activate MQTT logging? This would explain why you receive the message twice.

---

I'm considering changing the format of messages from:

tele/zigbee/SENSOR = {"0x0EB5":{"PressureUnit":"hPa","Pressure":1005}}
to
tele/zigbee/SENSOR = {"ZigbeeReceived":{"Device":"0x0EB5","PressureUnit":"hPa","Pressure":1005}}

It's possible since only one message can be sent or received at a time. It should also be easier to parse with static field names. I'm also considering adding metadata like friendlyname or linkquality:
tele/zigbee/SENSOR = {"ZigbeeReceived":{"Device":"0x0EB5","PressureUnit":"hPa","Pressure":1005,"Name":"Kitchen","Linkquality":128}}

Sending messages would look like:
ZigbeeSend {"Device":"0x1234","Power":"On"}
which I prefer over:
ZigbeeSend {"0x1234":{"Power":"On"}}
Or, with friendly name:
ZigbeeSend {"Name":"Kitchen-shutter","ShutterLift":50}

Thoughts?
@meingraham @Jason2866 @jziolkowski @arendst

[meingraham]

I prefer the named pair which labels each field explicitly. Specifically, and also the additional data.
{"ZigbeeReceived":{"Device":"0x0EB5","PressureUnit":"hPa","Pressure":1005,"Name":"Kitchen","Linkquality":128}}

And these:
ZigbeeSend {"Device":"0x1234","Power":"On"}

For Shutter commands, the current commands:
ShutterClose
ShutterOpen
ShutterStop
ShutterPosition

So?
ZigbeeSend {"Name":"Kitchen-shutter","ShutterPosition":50}

[tyjtyj]

I voted for this too

{"ZigbeeReceived":{"Device":"0x0EB5","PressureUnit":"hPa","Pressure":1005,"Name":"Kitchen","Linkquality":128}}

and
zibsend should take both either name or device

ZigbeeSend {"Device":"0x1234","Power":"On"}
ZigbeeSend {"Name":"Kitchen","Power":"On"}

[s-hadinger]

Thanks. Change done. Please note it will be a breaking change in the next PR.

@meingraham Here are the Zigbee shutter commands:
ShutterOpen no parameter
ShutterClose no parameter
ShutterStop no parameter
ShutterLift percentage 0..100, 0=open, 100=closed
ShutterTilt percentage 0..100

[Jason2866]

@s-hadinger i am fine with the suggestion from @meingraham
@jziolkowski has a lot of experience of json parsing -> TDM development... if the suggestion is the usual used structure.

[s-hadinger]

Here is an actual example of output:
21:59:21 MQT: tele/sonoff/Zigbee_home/SENSOR = {"ZigbeeReceived":{"Device":"0x7C71","Humidity":65.12,"LinkQuality":131}}

[jziolkowski]

As long as the keys are keys, and values are values then it's all fine. My only "objection" was to use the DeviceID as key; the "Device": "<id>" payload is okay.

[jziolkowski]

Is there a possibility that this reply will include two or more devices?

[s-hadinger]

No it’s not possible. Messages sent or received are mapped to a Zigbee message and can target only one address per message.

When sending you can broadcast but it will also be to a single address, namely 0xFFFF.

[jziolkowski]

Ok, then the payload is fine. I thought that if more than one device could reply in a single message then it would need some nesting, but if that's not the case then I don't have further questions :)

[tyjtyj]

@s-hadinger which version should i get now i compile zigbee_9_temp and got error

23:18:20 postProcessAttributes: wrong format for attribute : Device
23:18:20 postProcessAttributes: wrong format for attribute : Occupancy

[s-hadinger]

Ah... Yes... I forgot to remove this log that gives false errors.

You can safely ignore those messages for now.

The fix is already in the PR: #6702
Just wait for Theo to merge.

[tyjtyj]

ok. upgraded to lasted from arendst and looking great..

I found that pair device will always managed to send data to cc2530 even after i reset by running ZigbeeReset 1

Squence of event.

restart es8266
run "ZigbeeReset 1"
on the cc2530 ready, it start receive data from previously paired device.
Zigbeestatus 1 shows device with IEEEAddr 000000000000
run "Zigbeepermitjoin 1"
pair 2 device
Zigbeestatus 1 shows 3 device. 2 correct device and one with 000000000

sample below.

00:28:01 MQT: stat/zigbee/RESULT = 
{"ZigbeeStatus1":[{"Device":"0x21F3","IEEEAddr":"0000000000000000"},
{"Device":"0x302D","IEEEAddr":"00158D00041451AC","ModelId":"lumi.sensor_motion.aq2"},
{"Device":"0xE45F","IEEEAddr":"00158D00036B4BDC","ModelId":"lumi.weather","Manufacturer":"LUMI"}]}

[Jason2866]

@s-hadinger
for more than one device this format is bad. Every system which does Json parsing
has problems to separate devices because the device is a member of the measured values.
Better would be:
{"ZigbeeReceived":{"0x7C71": {"Temperature":21.33,"_LinkQuality":65}}}

[arendst]

I agree.

[tyjtyj]

@jziolkowski mentions key should not be device ID. @jason8266 proposal means we are back to square 1.

[s-hadinger]

@Jason2866 Let me send the fix in the following minutes.

@tyjtyj I might have overstated the effect of ZigbeeReset. This command forces a reconfiguration of the CC2530 but does not erase the previously recorded devices.

What you are seeing here is that device 0x21F3 continued to send data. After a reboot, Tasmota can't know the long address of 0x21F3 without probing or receiving a special packet. When you re-pair, a new address is assigned, but then Tasmota doesn't know what happened to 0x21F3 that got reassigned a new address.

I understand it's confusing but there's nothing I can easily do to avoid this. Let me look if there's a way to completely erase the CC2530 (without flashing).