Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Xiaomi Aqara double wireless wall switch (WXKG02LM) has the wrong ID in devices.js #4

Closed
rocketmonkeys opened this issue May 31, 2018 · 0 comments
Closed

Xiaomi Aqara double wireless wall switch (WXKG02LM) has the wrong ID in devices.js #4

rocketmonkeys opened this issue May 31, 2018 · 0 comments

Comments

@rocketmonkeys
Copy link

After pairing the WXKG02LM, any button action causes this in the log:

Device with modelID 'lumi.sensor_86sw2.es1' is not supported.

In devices.js we have:

'lumi.sensor_86sw2\u0000Un': {

But that should probably read:

'lumi.sensor_86sw2.es1': {

Same likely goes for the single key (WXKG03LM) which has lumi.sensor_86sw1\u0000lu. Not sure why we want unicode chars in here, but altering the file as mentioned above seems to work:

MQTT publish, topic: 'zigbee2mqtt/....', payload: '{"click":"left"}'
MQTT publish, topic: 'zigbee2mqtt/....', payload: '{"click":"right"}'
rocketmonkeys pushed a commit to rocketmonkeys/zigbee-shepherd-converters that referenced this issue May 31, 2018
@james-yoneda-ow
Fix for Koenkk#4 - correct modelID for Xiaomi Aqara double wireless w…
b15a32f 
…all switch (WXKG02LM).
@rocketmonkeys rocketmonkeys mentioned this issue May 31, 2018
Merged
Koenkk added a commit that referenced this issue May 31, 2018
@Koenkk
Merge pull request #5 from rocketmonkeys/4-xiaomi-aqara-double-wirele…
dd8651b 
…ss-switch-fix-modelid

Fix for #4 - correct modelID for Xiaomi Aqara double wireless wall sw…
@Koenkk Koenkk closed this as completed May 31, 2018
asgothian referenced this issue in asgothian/zigbee-herdsman-converters Jun 20, 2021
@asgothian
Merge pull request #4 from asgothian/Koenkk-master
543141c 
Koenkk master
@wb441 wb441 mentioned this issue Dec 15, 2021
Closed
gmbnomis added a commit to gmbnomis/zigbee-herdsman-converters that referenced this issue Jan 16, 2022
@gmbnomis
Improve tuya_data_point_dump: Log decoded DPs
d26c6c7 
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)).
gmbnomis added a commit to gmbnomis/zigbee-herdsman-converters that referenced this issue Jan 16, 2022
@gmbnomis
Improve tuya_data_point_dump: Log decoded DPs
8bd0785 
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)).
gmbnomis added a commit to gmbnomis/zigbee-herdsman-converters that referenced this issue Jan 16, 2022
@gmbnomis
Improve tuya_data_point_dump: Log decoded DPs
c7d5bd5 
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)).
gmbnomis added a commit to gmbnomis/zigbee-herdsman-converters that referenced this issue Jan 16, 2022
@gmbnomis
Improve tuya_data_point_dump: Log decoded DPs
a16f833 
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)).
Koenkk pushed a commit that referenced this issue Jan 16, 2022
@gmbnomis
Improve tuya_data_point_dump: Log decoded DPs (#3687)
914d095 
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)).
@alex005005 alex005005 mentioned this issue Dec 5, 2022
Closed
@dierochade dierochade mentioned this issue Jun 2, 2024
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@Koenkk @rocketmonkeys