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

Heatpump WLW186 with BC400/RC220 and failure message #1963

Open
UlfHRO opened this issue Aug 26, 2024 · 3 comments
Open

Heatpump WLW186 with BC400/RC220 and failure message #1963

UlfHRO opened this issue Aug 26, 2024 · 3 comments
Labels
enhancement New feature or request

Comments

@UlfHRO
Copy link

UlfHRO commented Aug 26, 2024

On my Buderus WLW186 heatpump with ems-esp 3.7.0-dev.32 I have successful communication, but failures and errors of the heatpump will not be indicated at the ems-esp. I have "created" a failure by disconnecting the outside temp sensor and the failure is correctly indicated a the hp and the rc, but no information or failure status indication in ems-esp...?! Is something missing here or are custom entities required to get the failure status of the hp...?

{
"system": {
"version": "3.7.0-dev.32",
"uptime": "000+01:03:34.989",
"uptimeSec": 3814,
"platform": "ESP32",
"arduino": "Tasmota Arduino v2.0.17",
"sdk": "4.4.8.240628",
"freeMem": 167,
"maxAlloc": 107,
"freeCaps": 4169,
"usedApp": 1685,
"freeApp": 4011,
"partition": "app0",
"resetReason": "Software reset CPU / Software reset CPU"
},
"network": {
"network": "Ethernet",
"hostname": "ems-esp",
"TxPowerSetting": 0,
"staticIP": false,
"lowBandwidth": false,
"disableSleep": true,
"enableMDNS": true,
"enableCORS": false,
"APProvisionMode": "disconnected",
"APSecurity": "wpa2",
"APSSID": "ems-esp"
},
"ntp": {
"NTPStatus": "connected",
"enabled": true,
"server": "time.google.com",
"tzLabel": "Europe/Amsterdam"
},
"mqtt": {
"MQTTStatus": "disconnected",
"enabled": false,
"clientID": "esp32-5ae2dec4",
"keepAlive": 60,
"cleanSession": true,
"entityFormat": 0,
"base": "ems-esp",
"discoveryPrefix": "homeassistant",
"discoveryType": 0,
"nestedFormat": 2,
"haEnabled": false,
"mqttQos": 0,
"mqttRetain": false,
"publishTimeHeartbeat": 60,
"publishTimeBoiler": 10,
"publishTimeThermostat": 10,
"publishTimeSolar": 10,
"publishTimeMixer": 10,
"publishTimeWater": 10,
"publishTimeOther": 60,
"publishTimeSensor": 10,
"publishSingle": false,
"publish2command": false,
"sendResponse": false
},
"syslog": {
"enabled": false
},
"sensor": {
"temperatureSensors": 0,
"temperatureSensorReads": 0,
"temperatureSensorFails": 0
},
"api": {
"APICalls": 4540,
"APIFails": 0
},
"bus": {
"busStatus": "connected",
"busProtocol": "Buderus",
"busTelegramsReceived": 21966,
"busReads": 3581,
"busWrites": 0,
"busIncompleteTelegrams": 1,
"busReadsFailed": 0,
"busWritesFailed": 0,
"busRxLineQuality": 100,
"busTxLineQuality": 100
},
"settings": {
"boardProfile": "E32V2",
"locale": "en",
"txMode": 2,
"emsBusID": 11,
"showerTimer": false,
"showerMinDuration": 180,
"showerAlert": false,
"hideLed": false,
"noTokenApi": false,
"readonlyMode": false,
"fahrenheit": false,
"dallasParasite": false,
"boolFormat": 6,
"boolDashboard": 1,
"enumFormat": 1,
"analogEnabled": false,
"telnetEnabled": false,
"maxWebLogBuffer": 100,
"webLogBuffer": 0,
"modbusEnabled": false
},
"devices": [
{
"type": "boiler",
"name": "CS6800i/WLW176i",
"deviceID": "0x08",
"productID": 8,
"brand": "Buderus",
"version": "00.00",
"entities": 162,
"handlersReceived": "0xBF 0x14 0xD1 0xE3 0xE4 0xE5 0xE9 0x0494 0x0495 0x048F",
"handlersFetched": "0xE6 0xEA 0x048D 0x04A2 0x0485 0x0486 0x0492 0x0488 0x0484 0x048B 0x0491 0x0499 0x049C 0x049D 0x04AE 0x04AF 0x02CC",
"handlersPending": "0x10 0x11 0xC2 0x15 0x1C 0x18 0x19 0x1A 0x35 0x16 0x33 0x34 0x26 0x2A 0x28 0x048A 0x04A5",
"handlersIgnored": "0x02D6 0x023E 0x0240 0x0291 0x0292 0x0293 0x0294 0x029B 0x02A5 0x02F5 0x04A8 0x04A9 0x04AA 0x04AB 0x04AC 0x04CA 0x04CB 0x04A7 0x04C0 0x02EA 0xE7 0x04F2 0x061E 0x04AD 0x17"
},
{
"type": "thermostat",
"name": "Rego 3000/UI800/WSW196i/BC400",
"deviceID": "0x10",
"productID": 253,
"brand": "",
"version": "47.10",
"entities": 71,
"handlersReceived": "0x06 0x02BA 0x02BB 0x02BC 0x031D 0x0267",
"handlersFetched": "0x02A5 0x02B9 0x02AF 0x029B 0x0471 0x02CC 0x0467 0x0291 0x0292 0x0293 0x0294 0x02F5 0x023A 0x0240 0xBB 0x023E",
"handlersPending": "0xA3 0xA2 0x12 0x13 0x02A6 0x02B0 0x029C 0x0472 0x02A7 0x02B1 0x029D 0x0473 0x02A8 0x02B2 0x029E 0x0474 0x02A9 0x02BD 0x02B3 0x029F 0x0475 0x02AA 0x02BE 0x02B4 0x02A0 0x0476 0x02AB 0x02BF 0x02B5 0x02A1 0x0477 0x02AC 0x02C0 0x02B6 0x02A2 0x0478 0x02CE 0x0468 0x02D0 0x0469 0x02D2 0x046A 0x02F6 0x031B 0x031E 0x0269",
"handlersIgnored": "0x0507 0x0508 0x0509 0x050A 0x059D 0x016E 0xBF"
},
{
"type": "thermostat",
"name": "RT800/RC220",
"deviceID": "0x38",
"productID": 3,
"brand": "",
"version": "21.04",
"entities": 3,
"handlersReceived": "0x042B 0x047B",
"handlersPending": "0x0273 0x0A6A",
"handlersIgnored": "0xBF"
},
{
"type": "gateway",
"name": "WiFi module",
"deviceID": "0x48",
"productID": 252,
"brand": "Buderus",
"version": "08.02",
"entities": 0,
"handlersIgnored": "0x04A7 0xF9 0x2040 0x0495 0x0494 0x04AF 0x04AE"
}
]
}

@MichaelDvP
Copy link
Contributor

The ems boilers store the last errors in telegram 0x10 and 0x11, ems+ in 0xC2, seems the heatpumps uses a different telegram type we don't know.
The actual error is published in telegram 0xBF, the boiler handlers indicate that it was received. But it's difficult to read the BF, it is only published on errors and reading always gives an empty answer when there is no error.
Try to log the telegrams and initiate an error. maybe we can see what telegram the heatpumps use.
Or you can use custom entities to monitor 0xBF
device 0x08, telegram 0xBF:
offset 0: UINT8 device id of error reporting device
offset 1: UINT8 product-ID
offset 4: UNT8 errortype enum: info, locking, blocking, system, reset
offset 5,6,7: 3 digit ASCII code
offset 8: UINT16 errorcode

But custom entity will only show up on error and is removed when the error is gone. It's not a permanent publish.

@UlfHRO
Copy link
Author

UlfHRO commented Aug 27, 2024

log.txt

Hallo,
Thanks for your feedback and suggestion...

Please find attached the logfile (Alarm created, Alarm cleared and reseted)...

I tried the above proposed custom entity and that works well with following observations:

  • Error code reported in esp is 6310, error code on the hp is 6311...?! Is there a plus 1 required for that field...?
  • The custom entity is continuously transmitted also if no error is active, but then with code 0, which is as expected...
  • Do you know the bit coding of the errortype enum? I received an enum with 6 (?) bits used... as number 41...

@MichaelDvP
Copy link
Contributor

I think errortype is what is listed here as class: https://www.manualslib.de/manual/258240/Buderus-Logamatic-Ems.html?page=17#manual

The log shows now that the error-log is stored in 0xC6 and 0xC7. I'm not sure about all the fields.
?(0xC6), data: 0B 08 08 00 0E 29 20 2D 2D 18 56 98 08 07 1B 29 00 00 00 00 00
first byte unknown, device 08, product 08, ?, class 0E, ASCII ") --", code 0x1856 = 6230, start at 27.08.2024 07:41 not stopped.
(date is year-month-hour-day-minute, with year 7bit from 2000 on 0x98 = 2000 + 0x18 = 2024) The zeros is date of error cleared.
Error in offset 42 is 09 08 08 00 0E 31 20 2D 2D 18 57 98 08 07 1B 1A 98 08 07 1B 27
ASCII "1 --", code 6231, 27.08.2024 07:26 until 27.08.2024 07:39

I'll check how to integrate in the last error publish...

@proddy proddy added the enhancement New feature or request label Oct 17, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

4 participants
@proddy @MichaelDvP @UlfHRO and others