HY09-GCWRW support?

[Stoatwblr]

https://www.aliexpress.com/item/4000689067944.html

This apears to be a more or less standard Tuya device driving a water heating boiler. I've actually flashed the -fas fork but I don't think this is fas specific

[solved, see below]
I cannot get it to join my wifi network (SSID is 10-chars mixed case alphanumeric, WPA2/3 pass 25 chars mixed case alphanumerica plus punctuation (?!"$%^&*(){}][#~@, etc)

After providing the SSID and password it reboots, loops a coupe of times and then falls back to AP mode

This isn't a general tasmota problem as my Tasmota devices are working fine

The wifi unit is a TYWE3S in the relay head unit

These can't be flashed OTA with tuya-convert but they can be flashed with usb-ttl serial and grounding gpio0 + disabling the 433MHz transceiver, per the annotations on the image below

[Stoatwblr]

Solved the networking problem:

(for some reason a space was being appended to the SSID on my android phone browser and I missed this. I'm leaving this here for anone else who might get caught out. It took 3 tries to clear this field on the browser)

[Stoatwblr]

NTP sync is working and transmitted to the controller over the 433MHz link

Set as HY08 device

Temperatures reporting OK (no floor temp) no relay/load status no reporting of schedules set on controller wifi "factory settings" button on front panel doesn't work "wifi signal" led is off and only flashes when there is traffic (this may confuse users. Tuya mode is "on" when connected and flashes for command traffic)

MQTT-explorer reports DEVname = {"error":"Unknown MCU command: 55 aa 00 07 00 05 76 04 00 01 00"}

the only connection between the TYWE3S and the rest of the unit is via TX/RX pins

[Stoatwblr]

[klausahrenberg]

Ok, thanks for report for this device. I will have a look at this in new year. Maybe I have to reorganize the firmware to reflect all the different models with different commands.

[tarasifua]

Hello! Any progress with that model?

[Stoatwblr]

None yet

I have contacted Hysen and asked for an API for the MCU, in order to get canonical data on DPids. No response yet

[Stoatwblr]

These DPids are all emitted every couple of minutes (settable in the B menu on the panel - B5 0-30min, B6 3-30 seconds - default is 20 mins, DON'T change it if using batteries in the panel or they will drain quickly)

OR whenever the clock is updated by Homeassistant, or if the panel mode/temperature, etc is changed

There's what appears to be a heartbeat as well, this is using type 1C clock reports (I'm ignoring it)

Hysen haven't responded

DPID table (I'll edit as I find more)

0x01 dpid 1 - panel display (also power led on wifi unit) 0x02 dpid 2 val(4) - target temp Cx10 1/70 0.5C step (should be limited to user settable range) 0x03 dpid 3 val(4) - actual temp Cx10 (0.5C step) (readonly) 0x04 dpid 4 enum - mode - 0=manual, 1=Auto, 2=Vacation 3=Auto+override 0c06 dpid 6 bool - Panel lock 0x66 dpid 102 bool - heat relay (binary sensor - readonly) 0x68 dpid 104 val(4) - Vacation timer (days) 1/30 0x69 dpid 105 val(4) - Vacation temperature (C) 1/70 1C step ( should be limited to user settable range) 0x6a dpid 106 bool - A5 overtemp protection enabled (should interlock with DPID 112) 0x6b dpid 107 bool - A6 frost protection enabled (should interlock with DPID 113) 0x6d dpid 109 val(4) - "A1" int sensor offset temp (Cx10) -9/+9 0.5C step 0x6e dpid 110 val(4) - "A2" int sensor temp hysteresis (Cx10) 0.5/5.0 0.5C step 0x6f dpid 111 val(4) - "A3" ext sensor temp hysteresis (C) 1/9 1C step (IF FITTED: not present on HY09) 0x70 dpid 112 val(4) - "A5" ext sensor overtemp threshold (C) 35/70 1C step (under 35 = disabled (See 1a)) 0x71 dpid 113 val(4) - "A6" int sensor frost protect temp (C) 1/10 1C step (over 10 = disabled (see 1b)) 0x72 dpid 114 val(4) - "A8" Maximum user-settable temperature C 20/70 1C step 0x73 dpid 115 val(4) - "A7" Minimum user-settable temperature C 1/10 1C step 0x74 dpid 116 enum - "B4" Sensor state 0=N1(int sensor),1=N2(ext sensor),N3(int+ext sensor) (see 2) - Overtemp protection disabled for sensor state 0,1 0x75 dpid 117 enum - "AA" Power off recovery: 0=resume 1=off 2=on 0x76 dpid 118 enum - "AB" Auto mode - 0=P1(5+2), 1=P2(6+1), 2=P3(7 days)

0x77 dpid 119: raw (value: 04.1E.14.08.00.0F.0B.1E.0F (9)) "04:30 20, 08:00 15,11:30 15" 0x77 dpid 119 raw(9) - Schedule Weekday period [1-3] (H:M:T, H:M:T, H:M:T) 0x78 dpid 120 raw(9) - Schedule Weekday period [4-6] (H:M:T, H:M:T, H:M:T) 0x79 dpid 121 raw(9) - Schedule Weekend period [1-3] (H:M:T, H:M:T, H:M:T) 0x7A dpid 122 raw(9) - Schedule Weekend period [4-6] (H:M:T, H:M:T, H:M:T)

UNKNOWNS

0x0c dpid 12 bitmask ??? - always 0? 0x65 dpid 101 bool ??? - always off (binary sensor) 0x67 dpid 103 val(4) ??? - always 0 (sensor - can't set) 0x6c dpid 108 bool ??? - always 1 (binary sensor - can't set)

NB:

1a: Setting A5 on the panel under 35c (DPID 112) automatically toggles DPID 106 off and changes the display to "[--]" 1b: Setting A6 on the panel over 11C (DPID 113) automatically toggles DPID 107 off and changes display to "[--]" 1c: There is no such interlock on remote access. Temperatures can be set arbitrarily high/low and the protection toggled

2: DPid 116 is assumed from HY02 decoding (see next comment). It's not adjustable if no external sensor circuitry is installed (ie: could be used to interlock internal/external sensor viewability)

3: Later versions of these Hysen devices are known to have Beken wifi modules, but the MCU commandset is apparently the same

The original app has commands to adjust panel display contrast/viewing angle, which I haven't yet managed to replicate

The original app also reported low battery on the remote panel but (so far) I haven't worked out where this is reported - I assumed it would be one of the unknown DPids but with the low battery icon flashing on the panel none of these have altered

[Stoatwblr]

Judging how the DPids match the HY08/HY02, I'm willing to bet that the unknowns are similar ( https://github.com/arendst/Tasmota/discussions/10513#discussioncomment-336368 )

On the other hand it's interesting how the divisors are different as are the scheule dpids

[Stoatwblr]

Another update (I'm using esphome for this at the moment)

23:12:09][C][tuya:041]: Tuya: [23:12:09][C][tuya:056]: Datapoint 1: switch (value: ON) [23:12:09][C][tuya:058]: Datapoint 2: int value (value: 150) [23:12:09][C][tuya:058]: Datapoint 3: int value (value: 215) [23:12:09][C][tuya:062]: Datapoint 4: enum (value: 1) [23:12:09][C][tuya:056]: Datapoint 6: switch (value: OFF) [23:12:09][C][tuya:064]: Datapoint 12: bitmask (value: 0) [23:12:09][C][tuya:056]: Datapoint 101: switch (value: OFF) [23:12:09][C][tuya:056]: Datapoint 102: switch (value: OFF) [23:12:09][C][tuya:058]: Datapoint 103: int value (value: 0) [23:12:09][C][tuya:058]: Datapoint 104: int value (value: 3) [23:12:09][C][tuya:058]: Datapoint 105: int value (value: 8) [23:12:09][C][tuya:056]: Datapoint 106: switch (value: OFF) [23:12:09][C][tuya:056]: Datapoint 107: switch (value: ON) [23:12:09][C][tuya:056]: Datapoint 108: switch (value: ON) [23:12:09][C][tuya:058]: Datapoint 109: int value (value: 0) [23:12:09][C][tuya:058]: Datapoint 110: int value (value: 15) [23:12:09][C][tuya:058]: Datapoint 111: int value (value: 5) [23:12:09][C][tuya:058]: Datapoint 112: int value (value: 40) [23:12:09][C][tuya:058]: Datapoint 113: int value (value: 10) [23:12:09][C][tuya:058]: Datapoint 114: int value (value: 30) [23:12:09][C][tuya:058]: Datapoint 115: int value (value: 5) [23:12:09][C][tuya:062]: Datapoint 116: enum (value: 0) [23:12:09][C][tuya:062]: Datapoint 117: enum (value: 0) [23:12:09][C][tuya:062]: Datapoint 118: enum (value: 0) [23:12:09][C][tuya:054]: Datapoint 119: raw (value: 04.1E.14.08.00.0F.0B.1E.0F (9)) [23:12:09][C][tuya:054]: Datapoint 120: raw (value: 0D.1E.0F.11.00.0F.16.00.0F (9)) [23:12:09][C][tuya:054]: Datapoint 121: raw (value: 06.00.14.08.00.0F.0B.1E.0F (9)) [23:12:09][C][tuya:054]: Datapoint 122: raw (value: 0D.1E.0F.11.00.0F.16.00.0F (9))

It's interesting to see DPIds 119/120 appear. This beings it to match the Hysen HY02 and it seems they're only emitted very infrequently or when schedules are changed - more importantly it means the schedules are trivially decoded/written

[Stoatwblr]

Ok, thanks for report for this device. I will have a look at this in new year. Maybe I have to reorganize the firmware to reflect all the different models with different commands.

Hopefully these updates will help :)

I suspect the next necessary step is to extract firmware from the STM (mtr7519) chips in order to see how the other commands are sent