Added device model to parser parameters #45 #1

kirovilya · 2018-05-23T19:01:45Z

No description provided.

Classic B40 TW - LIGHTIFY

Update to latest

Sync

2.0.46

* Master.support namron.2020.02.27 (#1) * Support Namron ZigBee 4 channel switch K8, model 4512703 Supports on/off and dimming on 4 endpoints * Allow dimmer buttons to dim all the way down to 0 and up to 255 * Remove extra spaces to make ESlint happy * Support Namron ZigBee 1 channel switch K4, model 4512702. Have separate buttons for on/off and dim up/down. * Support Namron ZigBee 1 channel switch K4, model 4512702. It has separate buttons for on/off and dim up/down. * Remove some spaces * Update devices.js * Update fromZigbee.js * Update fromZigbee.js * Update fromZigbee.js * Remove some previously added converters which is no more in use * Update fromZigbee.js * Update devices.js * Update devices.js Co-authored-by: Koen Kanters <koenkanters94@gmail.com>

* Add "discovery" mode for Xiaomi ZNCLDJ12LM (#1) * Add "discovery" mode for Xiaomi ZNCLDJ12LM Add "discovery" mode for Xiaomi ZNCLDJ12LM to calibrate end points * Add "discovery" mode for Xiaomi ZNCLDJ12LM Add "discovery" mode for Xiaomi ZNCLDJ12LM to calibrate end points * Remove tabs * Update toZigbee.js * Update devices.js * Update toZigbee.js * Update devices.js * Update fromZigbee.js * Update fromZigbee.js * Update toZigbee.js * Update toZigbee.js * Update toZigbee.js Co-authored-by: Koen Kanters <koenkanters94@gmail.com>

To Master

Adapt `scripts/read_tuya_dump.py` accordingly and make its output more helpful (print the numerical DP value and remove the `fn` field). Its output for a packet with two DP values now looks like this: ``` 2021-12-22T20:50:13 0x847127fffe0d03e3 (seq: 0, value: #0) [DP 1 unknown ] => enum: 1 2021-12-22T20:50:13 0x847127fffe0d03e3 (seq: 0, value: Koenkk#1) [DP 4 unknown ] => int: 92 ```

Adapt `scripts/read_tuya_dump.py` accordingly and make its output more helpful (print the numerical DP value and remove the `fn` field). Its output for a packet with two DP values now looks like this: ``` 2021-12-22T20:50:13 0x867829fffe2de210 (seq: 0, value: #0) [DP 1 unknown ] => enum: 1 2021-12-22T20:50:13 0x867829fffe2de210 (seq: 0, value: Koenkk#1) [DP 4 unknown ] => int: 92 ```

* Extend `tuya_data_point_dump` to support multiple DP values per payload Adapt `scripts/read_tuya_dump.py` accordingly and make its output more helpful (print the numerical DP value and remove the `fn` field). Its output for a packet with two DP values now looks like this: ``` 2021-12-22T20:50:13 0x867829fffe2de210 (seq: 0, value: #0) [DP 1 unknown ] => enum: 1 2021-12-22T20:50:13 0x867829fffe2de210 (seq: 0, value: #1) [DP 4 unknown ] => int: 92 ``` * Adapt TuYa "from Zigbee" converters to multiple data point change Types `commandDataReport`, `commandDataResponse`, and `commandActiveStatusReport` receive an array of DP values now (instead of a single value). Adapt existing converters to use the first entry of this array. To avoid breakage, additional DP values that may be present in a payload are ignored (as before). * Adapt TuYa library functions and "to Zigbee" converters to multiple data point change

Up to now, tuya_data_point_dump dumped the DP values in machine readable format, necessitating the use of the Python script `tuya_data_point_dump.py` to decode it. Additionally, the list of data point IDs in that script is not complete (actually, it is rather specific for Saswell devices). `zigbee-hardman-converters` actually has the most up-to-date list of DP values built-in. And it comes with DP value converters for the DP data types. We can use this to log incoming DP values in a human readable format containing the DP ID, data type, decoded value and the already known uses of the DP IP: ``` zigbee-herdsman-converters:tuya_data_point_dump: Received DP Koenkk#1 from 0x845134eaae1d0412 with raw data '{"dp":1,"datatype":4,"data":{"type":"Buffer","data":[1]}}': datatype='enum', value='1', known DP# usage: ["state","moesSsystemMode","moes105DimmerState1","trsPresenceState","haozeeSystemMode","nousTemperature","wlsWaterLeak"] zigbee-herdsman-converters:tuya_data_point_dump: Received DP Koenkk#4 from 0x845134eaae1d0412 with raw data '{"dp":4,"datatype":2,"data":{"type":"Buffer","data":[0,0,0,86]}}': datatype='value', value='86', known DP# usage: ["mode","moesSboostHeating","haozeeBoostHeating","nousBattery","wlsBatteryPercentage"] ``` In general, this output should be sufficient to enable new Tuya devices (However, this won't decode more complex data structures for Saswell devices (like tuya_data_point_dump.py does for schedules)).

Up to now, tuya_data_point_dump dumped the DP values in machine readable format, necessitating the use of the Python script `tuya_data_point_dump.py` to decode it. Additionally, the list of data point IDs in that script is not complete (actually, it is rather specific for Saswell devices). `zigbee-hardman-converters` actually has the most up-to-date list of DP values built-in. And it comes with DP value converters for the DP data types. We can use this to log incoming DP values in a human readable format containing the DP ID, data type, decoded value and the already known uses of the DP IP: ``` zigbee-herdsman-converters:tuya_data_point_dump: Received DP Koenkk#1 from 0x845134eaae1d0412 with raw data '{"dp":1,"datatype":4,"data":{"type":"Buffer","data":[1]}}': type='commandDataResponse' datatype='enum', value='1', known DP# usage: ["state","moesSsystemMode","moes105DimmerState1","trsPresenceState","haozeeSystemMode","nousTemperature","wlsWaterLeak"] zigbee-herdsman-converters:tuya_data_point_dump: Received DP Koenkk#4 from 0x845134eaae1d0412 with raw data '{"dp":4,"datatype":2,"data":{"type":"Buffer","data":[0,0,0,86]}}': type='commandDataResponse' datatype='value', value='86', known DP# usage: ["mode","moesSboostHeating","haozeeBoostHeating","nousBattery","wlsBatteryPercentage"] ``` In general, this output should be sufficient to enable new Tuya devices (However, this won't decode more complex data structures for Saswell devices (like tuya_data_point_dump.py does for schedules)).

Up to now, tuya_data_point_dump dumped the DP values in machine readable format, necessitating the use of the Python script `tuya_data_point_dump.py` to decode it. Additionally, the list of data point IDs in that script is not complete (actually, it is rather specific for Saswell devices). `zigbee-hardman-converters` actually has the most up-to-date list of DP values built-in. And it comes with DP value converters for the DP data types. We can use this to log incoming DP values in a human readable format containing the DP ID, data type, decoded value and the already known uses of the DP IP: ``` zigbee-herdsman-converters:tuya_data_point_dump: Received DP Koenkk#1 from 0x845134eaae1d0412 with raw data '{"dp":1,"datatype":4,"data":{"type":"Buffer","data":[1]}}': type='commandDataResponse', datatype='enum', value='1', known DP# usage: ["state","moesSsystemMode","moes105DimmerState1","trsPresenceState","haozeeSystemMode","nousTemperature","wlsWaterLeak"] zigbee-herdsman-converters:tuya_data_point_dump: Received DP Koenkk#4 from 0x845134eaae1d0412 with raw data '{"dp":4,"datatype":2,"data":{"type":"Buffer","data":[0,0,0,86]}}': type='commandDataResponse', datatype='value', value='86', known DP# usage: ["mode","moesSboostHeating","haozeeBoostHeating","nousBattery","wlsBatteryPercentage"] ``` In general, this output should be sufficient to enable new Tuya devices (However, this won't decode more complex data structures for Saswell devices (like tuya_data_point_dump.py does for schedules)).

Up to now, `tuya_data_point_dump` dumped the DP values in machine readable format, necessitating the use of the Python script `tuya_data_point_dump.py` to decode it. Additionally, the list of data point IDs in that script is not complete (actually, it is rather specific for Saswell devices). `zigbee-herdsman-converters` actually has the most up-to-date list of DP values built-in. And it comes with DP value converters for the DP data types. We can use this to log incoming DP values in a human readable format containing the DP ID, data type, decoded value and the already known uses of the DP IP: ``` zigbee-herdsman-converters:tuya_data_point_dump: Received DP Koenkk#1 from 0x845134eaae1d0412 with raw data '{"dp":1,"datatype":4,"data":{"type":"Buffer","data":[1]}}': type='commandDataResponse', datatype='enum', value='1', known DP# usage: ["state","moesSsystemMode","moes105DimmerState1","trsPresenceState","haozeeSystemMode","nousTemperature","wlsWaterLeak"] zigbee-herdsman-converters:tuya_data_point_dump: Received DP Koenkk#4 from 0x845134eaae1d0412 with raw data '{"dp":4,"datatype":2,"data":{"type":"Buffer","data":[0,0,0,86]}}': type='commandDataResponse', datatype='value', value='86', known DP# usage: ["mode","moesSboostHeating","haozeeBoostHeating","nousBattery","wlsBatteryPercentage"] ``` In general, this output should be sufficient to enable new Tuya devices (However, this won't decode more complex data structures for Saswell devices (like tuya_data_point_dump.py does for schedules)).

Up to now, `tuya_data_point_dump` dumped the DP values in machine readable format, necessitating the use of the Python script `tuya_data_point_dump.py` to decode it. Additionally, the list of data point IDs in that script is not complete (actually, it is rather specific for Saswell devices). `zigbee-herdsman-converters` actually has the most up-to-date list of DP values built-in. And it comes with DP value converters for the DP data types. We can use this to log incoming DP values in a human readable format containing the DP ID, data type, decoded value and the already known uses of the DP IP: ``` zigbee-herdsman-converters:tuya_data_point_dump: Received DP #1 from 0x845134eaae1d0412 with raw data '{"dp":1,"datatype":4,"data":{"type":"Buffer","data":[1]}}': type='commandDataResponse', datatype='enum', value='1', known DP# usage: ["state","moesSsystemMode","moes105DimmerState1","trsPresenceState","haozeeSystemMode","nousTemperature","wlsWaterLeak"] zigbee-herdsman-converters:tuya_data_point_dump: Received DP #4 from 0x845134eaae1d0412 with raw data '{"dp":4,"datatype":2,"data":{"type":"Buffer","data":[0,0,0,86]}}': type='commandDataResponse', datatype='value', value='86', known DP# usage: ["mode","moesSboostHeating","haozeeBoostHeating","nousBattery","wlsBatteryPercentage"] ``` In general, this output should be sufficient to enable new Tuya devices (However, this won't decode more complex data structures for Saswell devices (like tuya_data_point_dump.py does for schedules)).

* Update bosch.ts to fix support for BTH-RM230Z (#1) * Update bosch.ts to fix support for BTH-RM230Z - Added runningState to reflect if the floorheating is heating or idling - Added humidity - Removed screen orientation * format * Update src/devices/bosch.ts Co-authored-by: Koen Kanters <koenkanters94@gmail.com> * format * Update bosch.ts --------- Co-authored-by: Koen Kanters <koenkanters94@gmail.com>

* Implement message aging and avoid simultaneous sending of message queue * set sendZclFrameToEndpoint as default func for sendRequest * Refactor sendRequest, stricter type checks, return last send error * Update endpoint.ts --------- Co-authored-by: Koen Kanters <koenkanters94@gmail.com>

Add 'schedule', 'calibration' and more to ZWT07

This reverts commit aa84469, reversing changes made to 4ebf904.

Added device model to parser parameters #45

72722cb

Koenkk merged commit 5d2ddb8 into Koenkk:master May 23, 2018

Koenkk pushed a commit that referenced this pull request Jun 30, 2018

Merge pull request #1 from arteck/arteck-osram

338b42a

Classic B40 TW - LIGHTIFY

Koenkk pushed a commit that referenced this pull request Jul 30, 2018

Merge pull request #1 from Koenkk/master

2e57c6d

Update to latest

Koenkk pushed a commit that referenced this pull request Aug 8, 2018

Merge pull request #1 from Koenkk/master

73b5676

Sync

Koenkk pushed a commit that referenced this pull request Sep 5, 2018

Merge pull request #1 from Koenkk/master

0417ef7

2.0.46

mitnits mentioned this pull request Mar 17, 2019

Add support for Heiman 'SmartPlug' smart power plug #343

Closed

mclaudiopt mentioned this pull request May 11, 2019

Add support for SmartThings Multipurpose sensor (2018 version) #406

Closed

stkang mentioned this pull request Jul 27, 2019

Iris Motion and temperature sensor error #542

Closed

presslab-us mentioned this pull request Feb 14, 2021

Support Iris 3450-L Smart Fob #2238

Merged

benalla mentioned this pull request Mar 30, 2021

How to add this herdsman converters #2412

Closed

asgothian referenced this pull request in asgothian/zigbee-herdsman-converters Jun 20, 2021

Merge pull request #1 from Koenkk/master

cf97748

To Master

wb441 mentioned this pull request Dec 15, 2021

Ubisys D1: converters for dimming don't work as described #2842

Closed

BrainForge mentioned this pull request Oct 5, 2022

Add Tuya Smart Infrared Detector Motion Alarm Sensor #4740

Closed

karatatar pushed a commit to karatatar/zigbee-herdsman-converters that referenced this pull request Dec 1, 2024

Merge pull request Koenkk#1 from karatatar/master

aa84469

Add 'schedule', 'calibration' and more to ZWT07

karatatar added a commit to karatatar/zigbee-herdsman-converters that referenced this pull request Dec 1, 2024

Revert "Merge pull request Koenkk#1 from karatatar/master"

a5abdfe

This reverts commit aa84469, reversing changes made to 4ebf904.

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Added device model to parser parameters #45 #1

Added device model to parser parameters #45 #1

kirovilya commented May 23, 2018

Added device model to parser parameters #45 #1

Added device model to parser parameters #45 #1

Conversation

kirovilya commented May 23, 2018