arendst / Tasmota

Alternative firmware for ESP8266 and ESP32 based devices with easy configuration using webUI, OTA updates, automation using timers or rules, expandability and entirely local control over MQTT, HTTP, Serial or KNX. Full documentation at
https://tasmota.github.io/docs
GNU General Public License v3.0
22.16k stars 4.8k forks source link

Virtual Serialport / Zigbee Router with CC2530 #6095

Closed mar565 closed 5 years ago

mar565 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

@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 commented 5 years ago

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[bot] commented 5 years ago

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 commented 5 years ago

Work in progress

s-hadinger commented 5 years ago

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 commented 5 years ago

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

s-hadinger commented 5 years ago

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 commented 5 years ago

@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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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

s-hadinger commented 5 years ago

@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 commented 5 years ago

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.

tyjtyj commented 5 years ago

The wiki step are good. The missing 3.3v were mention and I did not do any further update to it.

@s-hadinger, how to you plan to assign kitchen to 0xC301 ?

I look further into my energy monitoring data and RFbridge from tasmota, RFBridge tele/rf/RESULT = {"RfReceived": "Sync":5460,"Low":190,"High":560,"Data":"90520D","RfKey":"None"}} PowerSensor tele/pwd/SENSOR = {"Time":"2019-09-25T11:00:21","ENERGY":{"TotalStartTime":"2019-04-01T15:07:12","Total":101.629,"Yesterday":0.015,"Today":0.060,"Period":0,"Power":1,"ApparentPower":12,"ReactivePower":11,"Factor":0.06,"Voltage":236,"Current":0.049}}

Suggested Zigbee tele/szigbee/sensor= {"ZigbeeZDTReceived": {"id":"0xC301","Pressure":1008,"PressureUnit":"hPa"}}

s-hadinger commented 5 years ago

I'm not sure it's useful to have "ZigbeeZDTReceived" in the received message. If we plan to have a friendly-name, it would look more like this: tele/<topic>/SENSOR = {"0xC301":{"Pressure":1008,"PressureUnit":"hPa"}} or tele/<topic>/SENSOR = {"Kitchen":{"Pressure":1008,"PressureUnit":"hPa"}}

In parallel, I improved the CCLib and CC_Proxy. You now need only 3 GPIOs instead of 4 to flash the CC2530 and flashing takes ~30 minutes instead of an hour.

meingraham commented 5 years ago

Messages that use a friendly name are good.

How does this get assigned? If one want's to query what the ID for Kitchen is, is there a command to do that?

tyjtyj commented 5 years ago

Having this to run for 2 days. I am pretty disappointed with CC2530 with antenna range. It barely cover 1/2 of my xiaomi gateway range. Current setup Xiaomi gateway ===3M===CC2530 ==5M==Temperature Sensor - CC2530 cant get the signal Means Xiaimi gateway ==========8M========Temperature Sensor - I got signal here

Which mean I need each of this in every room. Does CC2530 with external antenna and CC2591 RF front end makes significant different ?

How do you change channel on this ? and what is the channel it is currently running ?

s-hadinger commented 5 years ago

@meingraham This feature is not coded yet, so any suggestion is welcome.

@tyjtyj What CC2530 device do you own? You should definitely take a look at CC2530+CC2591. I haven't tried yet, they have reportedly much higher range than DL-20.

Channel can be changed with #define USE_ZIGBEE_CHANNEL 11. If you have multiple coordinators, you should also change PANID #define USE_ZIGBEE_PANID 0x1A63. Changing PanID requires re-pairing, changing Channel does not seem to require re-pairing.

You should also read this article about Wifi/Zigbee frequency overlaps.

tyjtyj commented 5 years ago

@S-hadinger, this type https://www.aliexpress.com/item/33007098493.html.

I reposition the antenna and I got 38 link quality instead of 18. I am using Ch 6 and 11 for WiFi and zigbee is channel 1(xiaomi hub cant change).

The battery always shows 100% I think it is aqara sensor issue.

I m ordering another wemo to make it permanent (soldering cable and proper case)

Again thanks for all the help. I am not fancy with friendly name but it a great feature Probably just SetZigbeeName 0x0030 'kitchen sensor' Lookup ZigbeeName 0x0030 Result kitchen sensor

Tollbringer commented 5 years ago

I have ordered the required devices to recreate and participate in this project. Thank you everyone. I will advise once product arrives in ~21 days. I have CC2530, CC2530 w/antenna, and CC2531 (current zigbee2mqtt alternative) to be able to help. I already have ZigBee2mqtt running with a few Xaomi temp sensors, and the CC debugger/programmer. I also have some incompatible Living wise sensors I am hoping to help make compatible.

[-=SrZ=-]

s-hadinger commented 5 years ago

@SirRedZ All the help to improve Zigbee is welcome.

We'll see about your Living wise sensors what we can do, but not being compatible with Zigbee2mqtt is not a good sign.

tyjtyj commented 5 years ago

Is motion sensor(xiaomi aqara) tested ?

I got null when motion detected. What should i receive when no motion. The number i assume is brightness.

02:46:56 MQT: tele/zigbee/RESULT = {"ZigbeeZNPReceived":"4481000000043FBC01010037000A9A2B00000818430A00002151003FBC1D"}
02:46:56 MQT: tele/zigbee/RESULT = {"ZigbeeZCLReceived":{"groupid":0,"clusterid":1024,"srcaddr":"0xBC3F","srcendpoint":1,"dstendpoint":1,"wasbroadcast":0,"linkquality":55,"securityuse":0,"seqnumber":0,"timestamp":2857482,"fc":"0x18","manuf":"0x0000","transact":67,"cmdid":"0x0A","payload":"0000215100"}}
02:46:56 MQT: tele/zigbee/RESULT = {"0xBC3F":{"0x04000000":81}}
02:46:56 MQT: tele/zigbee/RESULT = {"ZigbeeZNPReceived":"4481000006043FBC0101003700179A2B00000718440A000018013FBC1D"}
02:46:56 MQT: tele/zigbee/RESULT = {"ZigbeeZCLReceived":{"groupid":0,"clusterid":1030,"srcaddr":"0xBC3F","srcendpoint":1,"dstendpoint":1,"wasbroadcast":0,"linkquality":55,"securityuse":0,"seqnumber":0,"timestamp":2857495,"fc":"0x18","manuf":"0x0000","transact":68,"cmdid":"0x0A","payload":"00001801"}}
02:46:56 MQT: tele/zigbee/RESULT = {"0xBC3F":{"0x04060000":null}}
02:47:03 MQT: tele/zigbee/RESULT = {"ZigbeeZNPReceived":"4481000000043FBC0101003400DCEE2B00000818450A00002146003FBC1D"}
02:47:03 MQT: tele/zigbee/RESULT = {"ZigbeeZCLReceived":{"groupid":0,"clusterid":1024,"srcaddr":"0xBC3F","srcendpoint":1,"dstendpoint":1,"wasbroadcast":0,"linkquality":52,"securityuse":0,"seqnumber":0,"timestamp":2879196,"fc":"0x18","manuf":"0x0000","transact":69,"cmdid":"0x0A","payload":"0000214600"}}
02:47:03 MQT: tele/zigbee/RESULT = {"0xBC3F":{"0x04000000":70}}
02:47:03 MQT: tele/zigbee/RESULT = {"ZigbeeZNPReceived":"4481000006043FBC0101003400E8EE2B00000718460A000018013FBC1D"}
02:47:03 MQT: tele/zigbee/RESULT = {"ZigbeeZCLReceived":{"groupid":0,"clusterid":1030,"srcaddr":"0xBC3F","srcendpoint":1,"dstendpoint":1,"wasbroadcast":0,"linkquality":52,"securityuse":0,"seqnumber":0,"timestamp":2879208,"fc":"0x18","manuf":"0x0000","transact":70,"cmdid":"0x0A","payload":"00001801"}}
02:47:03 MQT: tele/zigbee/RESULT = {"0xBC3F":{"0x04060000":null}}
02:47:09 MQT: tele/zigbee/RESULT = {"ZigbeeZNPReceived":"4481000000043FBC0101003400AD3A2C00000818470A00002154003FBC1D"}
02:47:09 MQT: tele/zigbee/RESULT = {"ZigbeeZCLReceived":{"groupid":0,"clusterid":1024,"srcaddr":"0xBC3F","srcendpoint":1,"dstendpoint":1,"wasbroadcast":0,"linkquality":52,"securityuse":0,"seqnumber":0,"timestamp":2898605,"fc":"0x18","manuf":"0x0000","transact":71,"cmdid":"0x0A","payload":"0000215400"}}
02:47:09 MQT: tele/zigbee/RESULT = {"0xBC3F":{"0x04000000":84}}
02:47:09 MQT: tele/zigbee/RESULT = {"ZigbeeZNPReceived":"4481000006043FBC0101003400BA3A2C00000718480A000018013FBC1D"}
02:47:09 MQT: tele/zigbee/RESULT = {"ZigbeeZCLReceived":{"groupid":0,"clusterid":1030,"srcaddr":"0xBC3F","srcendpoint":1,"dstendpoint":1,"wasbroadcast":0,"linkquality":52,"securityuse":0,"seqnumber":0,"timestamp":2898618,"fc":"0x18","manuf":"0x0000","transact":72,"cmdid":"0x0A","payload":"00001801"}}
02:47:09 MQT: tele/zigbee/RESULT = {"0xBC3F":{"0x04060000":null}}
s-hadinger commented 5 years ago

Is motion sensor(xiaomi aqara) tested ?

Nope, you're the first one. Thansk for sharing the logs. Decoding is better in the latest version of Zigbee, I will improve it a little this week-end.

The data-type 0x18 was not yet supported, that's why the message shows 'null'.

Manually decoding, there 3 groups of 2 messages, they will look like the following with the upcoming PR:

Please not that 'Occupancy' is actually a bitmap, so you should test Least Significant Bit only.

tyjtyj commented 5 years ago

I updated to lastest Dev(10/10/2019) here is the logs look like.

22:44:54 MQT: tele/zigbee/RESULT = {"ZigbeeZNPReceived":"4481000000043FBC0101002C00F899E200000818500A00002141003FBC1D"}
22:44:54 MQT: tele/zigbee/RESULT = {"ZigbeeZCLReceived":{"groupid":0,"clusterid":1024,"srcaddr":"0xBC3F","srcendpoint":1,"dstendpoint":1,"wasbroadcast":0,"linkquality":44,"securityuse":0,"seqnumber":0,"timestamp":14850552,"fc":"0x18","manuf":"0x0000","transact":80,"cmdid":"0x0A","payload":"0000214100"}}
22:44:54 ZigbeeZCLRawReceived: {"0xBC3F":{"A_0400_0000":65}}
22:44:54 MQT: tele/zigbee/RESULT = {"0xBC3F":{"Illuminance":65}}
22:44:54 MQT: tele/zigbee/RESULT = {"ZigbeeZNPReceived":"4481000006043FBC0101002C00049AE200000718510A000018013FBC1D"}
22:44:54 MQT: tele/zigbee/RESULT = {"ZigbeeZCLReceived":{"groupid":0,"clusterid":1030,"srcaddr":"0xBC3F","srcendpoint":1,"dstendpoint":1,"wasbroadcast":0,"linkquality":44,"securityuse":0,"seqnumber":0,"timestamp":14850564,"fc":"0x18","manuf":"0x0000","transact":81,"cmdid":"0x0A","payload":"00001801"}}
22:44:54 ZigbeeZCLRawReceived: {"0xBC3F":{"A_0406_0000":null}}
22:44:54 MQT: tele/zigbee/RESULT = {"0xBC3F":{"Occupancy":null}}

I am about to move everything over and hit roadblock on 1st device. Anyway to find out which model already supported ? Currently I have xiaomi product Motion sensor (aqara and non aqara) Temperature sensor(aqara and non aqara) UK wall switch 1/2 gang (with neutral) UK wall switch 1 gang(without neutral) Round button switch

s-hadinger commented 5 years ago

Looks good, the rest is currently in my dev branch https://github.com/s-hadinger/Sonoff-Tasmota/commits/zigbee_8_temp

I will make a PR tomorrow as I need to change some stuff.

There is no way to know for sure if it works with CC2530. As a rule of thumb, if it is supported by Zigbee2Mqtt, there is a high chance it will work with Tasmota. https://www.zigbee2mqtt.io/information/supported_devices.html

Also keep in mind that the JSON format of messages may change. I will try to make it more consistent between receiving and sending messages.

s-hadinger commented 5 years ago

@tyjtyj New PR was lots of improvements!

tyjtyj commented 5 years ago

I got this approximately hourly...

I wonder occupancy sensor does sent temperature ? or it is just xiaomi bug.

23:45:21 MQT: tele/zigbee/RESULT = {"ZigbeeZNPReceived":"4481000000003FBC01010031005795C500002A1C5F11620A01FF42210121170C03281E0421A81305210500062401000000000A2100006410000B2100003FBC1D"}
23:45:21 MQT: tele/zigbee/RESULT = {"ZigbeeZCLReceived":{"groupid":0,"clusterid":0,"srcaddr":"0xBC3F","srcendpoint":1,"dstendpoint":1,"wasbroadcast":0,"linkquality":49,"securityuse":0,"seqnumber":0,"timestamp":12948823,"fc":"0x1C","manuf":"0x115F","transact":98,"cmdid":"0x0A","payload":"01FF42210121170C03281E0421A81305210500062401000000000A2100006410000B210000"}}
23:45:21 ZigbeeZCLRawReceived: {"0xBC3F":{"0000_0A_FF01":"0121170C03281E0421A81305210500062401000000000A2100006410000B210000"}}
23:45:21 MQT: tele/zigbee/RESULT = {"0xBC3F":{"Voltage":3.095,"Battery":100,"Temperature":0}}

This is when motion detected. Look good now .

04:11:50 MQT: tele/zigbee/RESULT = {"ZigbeeZNPReceived":"4481000000043FBC0101000D004105C300000818670A00002103003FBC1D"}
04:11:50 MQT: tele/zigbee/RESULT = {"ZigbeeZCLReceived":{"groupid":0,"clusterid":1024,"srcaddr":"0xBC3F","srcendpoint":1,"dstendpoint":1,"wasbroadcast":0,"linkquality":13,"securityuse":0,"seqnumber":0,"timestamp":12780865,"fc":"0x18","manuf":"0x0000","transact":103,"cmdid":"0x0A","payload":"0000210300"}}
04:11:50 ZigbeeZCLRawReceived: {"0xBC3F":{"0400_0A_0000":3}}
04:11:50 MQT: tele/zigbee/RESULT = {"0xBC3F":{"Illuminance":3}}
04:11:50 MQT: tele/zigbee/RESULT = {"ZigbeeZNPReceived":"4481000006043FBC0101000F004D05C300000718680A000018013FBC1D"}
04:11:50 MQT: tele/zigbee/RESULT = {"ZigbeeZCLReceived":{"groupid":0,"clusterid":1030,"srcaddr":"0xBC3F","srcendpoint":1,"dstendpoint":1,"wasbroadcast":0,"linkquality":15,"securityuse":0,"seqnumber":0,"timestamp":12780877,"fc":"0x18","manuf":"0x0000","transact":104,"cmdid":"0x0A","payload":"00001801"}}
04:11:50 ZigbeeZCLRawReceived: {"0xBC3F":{"0406_0A_0000":1}}
04:11:50 MQT: tele/zigbee/RESULT = {"0xBC3F":{"Occupancy":1}}
s-hadinger commented 5 years ago

Hmmm. Attribute "0000_0A_FF01" is a proprietary field from Xiaomi, and it is undocumented.

With lumi.weather, sub-field 0x64 is the Temperature, 0x65 is Humidity and 0x66 is Pressure. Unfortunately with your sensor 0x64 is of type Boolean and seems to be Occupancy. I need to find a way to disambiguate between different Aqara devices.

Your sensor sends "manuf":"0x115F" which is a specific manufacturer id. This may help to disambiguate. The Lumi.weather does not have this field set.

Do you have two or more of these devices? Can you check they have the same value for "manuf" field?

s-hadinger commented 5 years ago

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

tyjtyj commented 5 years ago
05:11:35 CMD: ZigbeeStatus 1
05:11:35 MQT: stat/zigbee/RESULT = {"ZigbeeStatus1":[{"ShortAddr":"0xBC3F","IEEEAddr":"0000000000000000"}]}
s-hadinger commented 5 years ago

@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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

Thanks for posting logs.

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

tyjtyj commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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"}