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.

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

Update exposes.js #1

Merged
merged 1 commit into from
Jun 4, 2021
Merged

Update exposes.js #1

merged 1 commit into from
Jun 4, 2021

Conversation

vladi1234
Copy link
Owner

No description provided.

@vladi1234 vladi1234 merged commit d11657d into master Jun 4, 2021
@vladi1234 vladi1234 deleted the vladi1234-patch-1 branch June 4, 2021 07:50
vladi1234 pushed a commit that referenced this pull request Jan 5, 2022
* 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
vladi1234 pushed a commit that referenced this pull request Jan 29, 2022
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)).
vladi1234 pushed a commit that referenced this pull request Dec 18, 2023
* 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>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
1 participant