This repository has been archived by the owner on Oct 4, 2021. It is now read-only.
Control both HC1 & HC2 at the same time in Home Assistant (MQTT) #162
Labels
enhancement
New feature or request
Comments
|
Hi @Frederik-V, yes it's possible to extend the MQTT to support multiple Heating Circuits. Easiest is to have two sets of MQTT messages so you can add two climate components to HA. It would need some additional code changes to fetch the thermostat values from the multiple HCs and store them. The difficulty is always testing these. Are you comfortable making code changes yourself to EMS-ESP ? |
|
Hi @proddy, unfortunately I do not have any experience to make code changes into the EMS-ESP. |
|
Hi proddy, I have a Buderus with 2 heat circuits and 2 separate thermostats an RC35 as main device and RMF20 for the first floor.
As you can see in the screenshot the temperature is switching between the 2 locations Hope you able to enhance the software that the HC setting is linked to a dedicated thermostat and will be able to read out both independently Thanks in advance |
|
This a bug, I'll add some extra functionality to read multiple heating circuits to the dev build |
|
@lmdecroos I'm adding supporting for multiple Heating Circuits. Adding additional thermostats will be more work. Can you answer these questions
|
proddy
added a commit
that referenced
this issue
Sep 7, 2019
|
Hi proddy,
I have one RC35 and one RFM20 ( RC20 wireless)
The RC35 is used for programming the boiler settings and to control HC1 for heating on the ground floor
The RC20 is used to control HC2 for our heating on the fist floor.
They are both working independently .
When asking for "info” the gateway stays that i have an RC35
Thermostat stats:
Thermostat: RC35 (ProductID:86 Version:21.08)
When requesting an autodetect
Started scan on EMS bus for known devices
Boiler found: Nefit Topline Compact/Buderus GB162 (DeviceID:0x08 ProductID:115 Version:05.05)
Device found: BC10/RFM20 Receiver (DeviceID:0x09 ProductID:68 Version:02.03)
Device found: WM10 Switch Module (DeviceID:0x11 ProductID:71 Version:02.00)
The gateway recognise also the switch for the pumps to control both HC’s
I had a look at the telegram messages in the EMS gateway and the MQTT received by Domoticz and it seems that the EMS gateway receives the temperature details from both heat circuit and send them both to the MQTT host.
The EMS software doesn’t filter the message based on the selected HC in the EMS configuration. Therefore the actual temperature in the MQTT message is switching between both HC’s ( thermostats)
The MQTT messages includes the correct HC (thermostat_hc) as set in the EMS gateway, but send always as current temperature the temperature from last received telegram message.
I would assume that you have to build in a filter based on the selected HC to only send the temperature from the selected HC
Logs with HC1 selected:
System Logging set to Thermostat only
(03:49:30.725) Thermostat -> all, type 0x06, telegram: 10 00 06 00 13 09 12 07 14 2B 05 01 (CRC=A6) #data=8
(03:49:30.995) Thermostat -> all, type 0x3E, telegram: 10 00 3E 00 00 00 00 00 C5 00 00 00 00 00 00 00 00 11 05 04 (CRC=AD) #data=16
Publishing thermostat data via MQTT
(03:49:32.245) Thermostat -> all, type 0x48, telegram: 10 00 48 00 00 10 00 00 B4 00 00 00 00 00 00 00 00 11 05 04 (CRC=C8) #data=16
Publishing thermostat data via MQTT
(03:49:32.542) Thermostat -> all, type 0xA3, telegram: 10 00 A3 00 6E 11 00 00 C5 00 CB 00 CB 7D 00 7D 00 (CRC=D8) #data=13
(03:49:48.462) Thermostat -> 0x21, type 0xAC, telegram: 10 21 AC 00 05 00 01 (CRC=0F) #data=3
(03:49:57.581) Thermostat -> Boiler, type 0x35, telegram: 10 08 35 00 11 01 (CRC=20) #data=2
(03:49:57.708) Thermostat -> 0x11, type 0x9D, telegram: 10 11 9D 00 00 (CRC=D7) #data=1
Publishing boiler data via MQTT
Publishing hot water and heating states via MQTT
Publishing thermostat data via MQTT
Requesting scheduled EMS device data
(03:50:01.243) Thermostat -> me, type 0x3E, telegram: 10 0B 3E 00 00 00 00 00 C5 00 00 00 00 00 00 00 00 11 05 04 (CRC=C5) #data=16
Publishing thermostat data via MQTT
(03:50:01.556) Thermostat -> me, type 0x3D, telegram: 10 0B 3D 00 01 1E 26 22 00 28 00 00 00 05 05 2D 01 01 04 4B 05 4B 01 00 3C FF 11 05 05 02 02 (CRC=43) #data=27
Publishing thermostat data via MQTT
(03:50:01.869) Thermostat -> me, type 0x06, telegram: 10 0B 06 00 13 09 12 07 15 0E 05 01 (CRC=9D) #data=8
Publishing boiler data via MQTT
(03:50:06.364) Thermostat -> all, type 0xA2, telegram: 10 00 A2 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 (CRC=99) #data=14
(03:50:08.954) Thermostat -> Boiler, type 0x14, telegram: 10 88 14 00 03 (CRC=6E) #data=1
(03:50:08.967) Boiler -> Thermostat, type 0x14, telegram: 08 10 14 00 32 81 BA (CRC=30) #data=3
(03:50:17.710) Thermostat -> Boiler, type 0x1A, telegram: 10 08 1A 00 00 00 00 00 (CRC=91) #data=4
(03:50:31.225) Thermostat -> all, type 0x06, telegram: 10 00 06 00 13 09 12 07 15 2B 05 01 (CRC=AE) #data=8
(03:50:31.494) Thermostat -> all, type 0x3E, telegram: 10 00 3E 00 00 00 00 00 C5 00 00 00 00 00 00 00 00 11 05 04 (CRC=AD) #data=16
Publishing boiler data via MQTT
(03:50:32.744) Thermostat -> all, type 0x48, telegram: 10 00 48 00 00 10 00 00 B4 00 00 00 00 00 00 00 00 11 05 04 (CRC=C8) #data=16
Publishing thermostat data via MQTT
(03:50:33.039) Thermostat -> all, type 0xA3, telegram: 10 00 A3 00 6E 11 00 00 C5 00 CB 00 CB 7D 00 7D 00 (CRC=D8) #data=13
2019-09-07 18:22:11.643 (Buderus - System Pressure) Updating device from 1:'1' to have values 1:'1'.
2019-09-07 18:22:11.649 (Buderus) Current temp: 62.8
2019-09-07 18:22:11.649 (Buderus - Warmwater) Updating device from 1:'62.8' to have values 1:'62.8'.
2019-09-07 18:22:11.654 (Buderus) Current temp: 56.1
2019-09-07 18:22:11.654 (Buderus - Boiler) Updating device from 1:'56.1' to have values 1:'56.1'.
2019-09-07 18:22:11.659 (Buderus) Burner: off
2019-09-07 18:22:12.912 (Buderus) MQTT message: home/ems-esp/thermostat_data b'{"thermostat_hc":"1","thermostat_seltemp":0,"thermostat_currtemp":18,"thermostat_daytemp":19,"thermostat_nighttemp":15,"thermostat_holidayttemp":17,"thermostat_heatingtype":1,"thermostat_circuitcalctemp":5,"thermostat_mode":"night"}'
2019-09-07 18:22:12.912 (Buderus) Current temp: 18.0
2019-09-07 18:22:12.912 (Woonkamer) Updating device from 1:'19.7' to have values 1:'18.0'.
2019-09-07 18:22:12.918 (Buderus) Temp setting: 0
2019-09-07 18:22:12.918 (Buderus - Nefit) Updating device from 1:'0' to have values 1:'0'.
2019-09-07 18:22:19.335 (Buderus) Heartbeating...
2019-09-07 18:22:19.336 (Buderus) MqttClient::Ping
2019-09-07 18:22:29.305 (Buderus) Heartbeating...
2019-09-07 18:22:29.305 (Buderus) MqttClient::Ping
2019-09-07 18:22:39.322 (Buderus) Heartbeating...
2019-09-07 18:22:39.322 (Buderus) MqttClient::Ping
2019-09-07 18:22:42.178 (Buderus) MQTT message: home/ems-esp/boiler_data b'{"wWComfort":"Hot","wWSelTemp":58,"selFlowTemp":7,"selBurnPow":0,"curBurnPow":0,"pumpMod":0,"wWCurTmp":62.8,"wWCurFlow":0,"curFlowTemp":48.9,"retTemp":52.8,"sysPress":1,"boilTemp":56.1,"wWActivated":"on","burnGas":"off","heatPmp":"off","fanWork":"off","ignWork":"off","wWCirc":"off","wWHeat":"off","burnStarts":26051,"burnWorkMin":401798,"heatWorkMin":362810,"ServiceCode":"0H","ServiceCodeNumber":203}'
2019-09-07 18:22:42.178 (Buderus) System Pressure: 1
2019-09-07 18:22:42.179 (Buderus - System Pressure) Updating device from 1:'1' to have values 1:'1'.
2019-09-07 18:22:42.184 (Buderus) Current temp: 62.8
2019-09-07 18:22:42.184 (Buderus - Warmwater) Updating device from 1:'62.8' to have values 1:'62.8'.
2019-09-07 18:22:42.189 (Buderus) Current temp: 56.1
2019-09-07 18:22:42.189 (Buderus - Boiler) Updating device from 1:'56.1' to have values 1:'56.1'.
2019-09-07 18:22:42.194 (Buderus) Burner: off
2019-09-07 18:22:42.195 (Buderus) MQTT message: home/ems-esp/thermostat_data b'{"thermostat_hc":"1","thermostat_seltemp":0,"thermostat_currtemp":19.7,"thermostat_daytemp":19,"thermostat_nighttemp":15,"thermostat_holidayttemp":17,"thermostat_heatingtype":1,"thermostat_circuitcalctemp":5,"thermostat_mode":"night"}'
2019-09-07 18:22:42.195 (Buderus) Current temp: 19.7
2019-09-07 18:22:42.195 (Woonkamer) Updating device from 1:'18.0' to have values 1:'19.7'.
2019-09-07 18:22:42.200 (Buderus) Temp setting: 0
2019-09-07 18:22:42.200 (Buderus - Nefit) Updating device from 1:'0' to have values 1:'0'.
2019-09-07 18:22:45.312 (Buderus) MQTT message: home/ems-esp/boiler_data b'{"wWComfort":"Hot","wWSelTemp":58,"selFlowTemp":7,"selBurnPow":0,"curBurnPow":0,"pumpMod":0,"wWCurTmp":62.8,"wWCurFlow":0,"curFlowTemp":48.9,"retTemp":52.8,"sysPress":1,"boilTemp":55.9,"wWActivated":"on","burnGas":"off","heatPmp":"off","fanWork":"off","ignWork":"off","wWCirc":"off","wWHeat":"off","burnStarts":26051,"burnWorkMin":401798,"heatWorkMin":362810,"ServiceCode":"0H","ServiceCodeNumber":203}'
2019-09-07 18:22:45.312 (Buderus) System Pressure: 1
2019-09-07 18:22:45.312 (Buderus - System Pressure) Updating device from 1:'1' to have values 1:'1'.
2019-09-07 18:22:45.318 (Buderus) Current temp: 62.8
2019-09-07 18:22:45.318 (Buderus - Warmwater) Updating device from 1:'62.8' to have values 1:'62.8’.
logs with HC2 selected :
2019-09-07 18:43:20.681 (Buderus) MQTT message: home/ems-esp/thermostat_data b'{"thermostat_hc":"2","thermostat_seltemp":0,"thermostat_currtemp":19.7,"thermostat_daytemp":18,"thermostat_nighttemp":13.5,"thermostat_holidayttemp":17,"thermostat_heatingtype":1,"thermostat_circuitcalctemp":5,"thermostat_mode":"night"}'
2019-09-07 18:43:20.681 (Buderus) Current temp: 19.7
2019-09-07 18:43:20.681 (Woonkamer) Updating device from 1:'17.7' to have values 1:'19.7'.
2019-09-07 18:43:20.686 (Buderus) Temp setting: 0
2019-09-07 18:43:20.686 (Buderus - Nefit) Updating device from 1:'0' to have values 1:'0'.
2019-09-07 18:43:22.544 (Buderus) MQTT message: home/ems-esp/thermostat_data b'{"thermostat_hc":"2","thermostat_seltemp":0,"thermostat_currtemp":17.7,"thermostat_daytemp":18,"thermostat_nighttemp":13.5,"thermostat_holidayttemp":17,"thermostat_heatingtype":1,"thermostat_circuitcalctemp":5,"thermostat_mode":"night"}'
2019-09-07 18:43:22.545 (Buderus) Current temp: 17.7
2019-09-07 18:43:22.545 (Woonkamer) Updating device from 1:'19.7' to have values 1:'17.7'.
2019-09-07 18:43:22.550 (Buderus) Temp setting: 0
Please let me know if you need more or other logs
Hope this helps
Thanks in advance
… On 7 Sep 2019, at 10:30, Paul ***@***.***> wrote:
@lmdecroos <https://github.com/lmdecroos> I'm adding supporting for multiple Heating Circuits. Adding additional thermostats will be more work. Can you answer these questions
does EMS-ESP detect both your RC35 thermostats?
do each of the thermostats report value for both the 2 heating circuits?
can you do a 'log t' and send me some examples of telegrams 0x3E (HC1) and 0x48 (HC2) so I can build some test data. I don't have an RC35 so it'll be a lot of trial and error. be prepared to do a lot of testing!
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub <#162>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ANDW44ZJKHHCFUSAFTOS4P3QINRBVANCNFSM4IGOZDBQ>.
|
|
I spent some time today to implement handling of multiple HCs independently. It's checked into the dev branch 1.9.1 so give it whirl. It's far from perfect and I still need to decide on the mqtt format for driving multiple heating circuits. |
|
I compiled the 1.9.1 dev branch and have unfortunately issues to get the gateway stable (similar as with the release version)
The connection to be EMS bus is unstable and crashes ( the led is flashing)
When using the 1.9.x version, every time I’m doing a telnet to the gateway the gateway start scanning the EMS bus
… On 7 Sep 2019, at 20:42, Paul ***@***.***> wrote:
I spent some time today to implement handling of multiple HCs independently. It's checked into the dev branch 1.9.1 so give it whirl. It's far from perfect and I still need to decide on the mqtt format for driving multiple heating circuits.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub <#162>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ANDW447IVH4DOTYCWWTBN73QIPYYPANCNFSM4IGOZDBQ>.
|
|
@lmdecroos When EMS-ESP starts it will auto-detect all known devices, this only happens once and should take a few seconds. If the Tx is not working this will fail, but shouldn't repeat. You can try different tx_modes (1 is default, 2 is EMS+ and 3 is Junkers). I've seen others report back that 1.9 keeps crashing but I cannot reproduce and I have no example logs, stacks etc to help pinpoint the issue. Is it really crashing (i.e. resetting)? See https://github.com/proddy/EMS-ESP/wiki/Troubleshooting |
|
when using the default EMS protocol, the gateway crashes shortly and resets the serial value to on. the web UI seems to know that i have a RC35, but the console scans every time the EMS bus ( when starting a telnet session) and then crashes even before i’m try to change the log level
when using the EMS+ protocol, then the gateway is stable but reads only the boiler values, there is no information or update from the thermostat. in the web UI there is only info about the boiler. there is also no information about the thermostat in the temp & verbose logs
… On 10 Sep 2019, at 04:14, Paul ***@***.***> wrote:
@lmdecroos <https://github.com/lmdecroos> When EMS-ESP starts it will auto-detect all known devices, this only happens once and should take a few seconds. If the Tx is not working this will fail, but shouldn't repeat. You can try different tx_modes (1 is default, 2 is EMS+ and 3 is Junkers). I've seen others report back that 1.9 keeps crashing but I cannot reproduce and I have no example logs, stacks etc to help pinpoint the issue. Is it really crashing (i.e. resetting)? See https://github.com/proddy/EMS-ESP/wiki/Troubleshooting <https://github.com/proddy/EMS-ESP/wiki/Troubleshooting>
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub <#162>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ANDW447UHYBDDLCLJU3BYDLQI37ILANCNFSM4IGOZDBQ>.
|
|
@lmdecroos could you create a separate issue for this problem as this one is related to a feature request to support multiple heating circuits. |
|
Yes, I can create a separate issue. But the EMS communication issues are introduced with version 1.9.x
With version 1.8.3 my RC35 thermostat was recognised by using the ems protocol ( tx_mode 1)
With version 1.9.0 and 1.9.1b the ems protocol chraches the gateway :
System Logging set to None
System Logging set to Verbose
(00:00:05.704) Sending read of type 0x02 to 0x38, telegram: 0B B8 02 00 20 (CRC=25)
(00:00:06.476) Boiler -> all, type 0x34, telegram: 08 00 34 00 3D 02 72 02 72 21 00 00 03 00 00 98 A7 00 15 3C 00 80 00 (CRC=4A) #data=19
<--- UBAMonitorWWMessage(0x34)
(00:00:06.706) Boiler -> all, type 0x18, telegram: 08 00 18 00 3D 02 89 72 00 00 00 64 60 02 67 02 72 02 82 00 00 0D 30 41 01 31 00 01 00 (CRC=A4) #data=25
<--- UBAMonitorFast(0x18)
(00:00:06.949) Sending read of type 0x02 to 0x02, telegram: 0B 82 02 00 20 (CRC=EC)
(00:00:08.112) Boiler -> all, type 0x07, telegram: 08 00 07 00 03 03 00 00 00 00 00 00 00 00 00 00 00 (CRC=53) #data=13
(00:00:08.518) Sending read of type 0x02 to 0x08, telegram: 0B 88 02 00 20 (CRC=BC)
(00:00:08.558) Boiler -> me, type 0x02, telegram: 08 0B 02 00 73 05 05 00 00 00 00 00 00 00 (CRC=D7) #data=10
<--- Version(0x02)
Boiler found: Nefit Topline Compact/Buderus GB162 (DeviceID:0x08 ProductID:115 Version:05.05)
(00:00:08.636) Boiler -> all, type 0x07, telegram: 08 00 07 00 0B 03 00 00 00 00 00 00 00 00 00 00 00 (CRC=7F) #data=13
(00:00:08.892) Sending read of type 0x02 to 0x09, telegram: 0B 89 02 00 20 (CRC=B4)
(00:00:08.930) 0x09 -> me, type 0x02, telegram: 09 0B 02 00 44 02 03 (CRC=25) #data=3
<--- Version(0x02)
Device found: BC10/RFM20 Receiver (DeviceID:0x09 ProductID:68 Version:02.03)
(00:00:09.240) Sending read of type 0x02 to 0x10, telegram: 0B 90 02 00 20 (CRC=7C)
(00:00:09.279) 0x10 -> me, type 0x02, telegram: 10 0B 02 00 56 15 08 (CRC=5E) #data=3
<--- Version(0x02)
Thermostat found: RC35 (DeviceID:0x10 ProductID:86 Version:21.08)
* Setting Thermostat to RC35 (DeviceID:0x10 ProductID:86 Version:21.08)
Requesting type RC35StatusMessage_HC1(0x3E) from dest 0x10
Requesting type RC35Set_HC1(0x3D) from dest 0x10
Requesting type RC35StatusMessage_HC2(0x48) from dest 0x10
Requesting type RC35Set_HC2(0x47) from dest 0x10
Requesting type RC35StatusMessage_HC3(0x52) from dest 0x10
Requesting type RC35Set_HC2(0x51) from dest 0x10
Requesting type RC35StatusMessage_HC4(0x5C) from dest 0x10
Requesting type RC35Set_HC4(0x5B) from dest 0x10
Requesting type RCTime(0x06) from dest 0x10
(00:00:09.539) Sending read of type 0x02 to 0x11, telegram: 0B 91 02 00 20 (CRC=74)
(00:00:09.584) 0x11 -> me, type 0x02, telegram: 11 0B 02 00 47 02 00 (CRC=7C) #data=3
<--- Version(0x02)
Device found: WM10 Switch Module (DeviceID:0x11 ProductID:71 Version:02.00)
(00:00:09.813) Sending read of type 0x02 to 0x17, telegram: 0B 97 02 00 20 (CRC=44)
(00:00:10.417) Boiler -> all, type 0x18, telegram: 08 00 18 00 07 02 88 00 00 00 00 40 60 02 69 02 73 02 81 00 00 0A 30 48 00 CB 00 00 00 (CRC=25) #data=25
<--- UBAMonitorFast(0x18)
(00:00:10.677) 0x11 -> Boiler, type 0x1E, telegram: 11 08 1E 00 00 CD (CRC=AF) #data=2
(00:00:10.984) Sending read of type 0x02 to 0x18, telegram: 0B 98 02 00 20 (CRC=3C)
The gateway hangs every time on : Sending read of type 0x02 to 0x18, telegram: 0B 98 02 00 20 (CRC=3C) and reboots itself afterwards
When using the EMS+ protocol (tx_mode 2) the gateway works stable, but doesn’t recognise my RC35 thermostat
the EMS+ protocol recognises only my boiler ( same for version 1.8.3)
… On 11 Sep 2019, at 05:23, Paul ***@***.***> wrote:
@lmdecroos <https://github.com/lmdecroos> could you create a separate issue for this problem as this one is related to a feature request to support multiple heating circuits.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub <#162>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ANDW44ZAX3MZ4BHTMWZBTVTQJBQEDANCNFSM4IGOZDBQ>.
|
|
I’m now testing the 1.9.1b2 build and wondering how i can set and check the HC in the console.
I’m able to change the setting in the web UI, but when using the "set heating_circuit” command i get the error message "Invalid parameter for set command”
|
|
You don’t need to set the heating circuit anymore. It should detect readings on up to 4 HCs automatically. I forgot to remove it from the web interface. |
|
see also https://github.com/proddy/EMS-ESP/wiki/MQTT on how to use MQTT to control multiple heating circuits. |
|
Thanks for updating the MQTT wiki, but I'm still suffer to get my thermostat / HC recognised in version 1.9.x
With the standard EMS protocol, both my boiler and HC are recognised in version 1.8.3, but when using version 1.9.x the EMS gateway crashes at startup while polling the bus.
The gateway hangs every time on : Sending read of type 0x02 to 0x18, telegram: 0B 98 02 00 20 (CRC=3C) and reboots itself afterwards, see my entry from 11th September.
I tested this messages in version 1.8.3, and then the 18.3 EMS gateway crashes also.
Can you advise where I have to look in the source code for the initiation and startup process, so that I can troubleshoot by check the differences between both versions.
… On 14 Sep 2019, at 16:41, Paul ***@***.***> wrote:
see also https://github.com/proddy/EMS-ESP/wiki/MQTT <https://github.com/proddy/EMS-ESP/wiki/MQTT> on how to use MQTT to control multiple heating circuits.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub <#162>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ANDW447T7JESJOOX3ULDVWLQJTZZNANCNFSM4IGOZDBQ>.
|
|
I‘d suggest ‚set log j‘ to get an idea where it happens...
Sent by mobile device
… Am 14.09.2019 um 17:26 schrieb lmdecroos ***@***.***>:
Thanks for updating the MQTT wiki, but I'm still suffer to get my thermostat / HC recognised in version 1.9.x
With the standard EMS protocol, both my boiler and HC are recognised in version 1.8.3, but when using version 1.9.x the EMS gateway crashes at startup while polling the bus.
The gateway hangs every time on : Sending read of type 0x02 to 0x18, telegram: 0B 98 02 00 20 (CRC=3C) and reboots itself afterwards, see my entry from 11th September.
I tested this messages in version 1.8.3, and then the 18.3 EMS gateway crashes also.
Can you advise where I have to look in the source code for the initiation and startup process, so that I can troubleshoot by check the differences between both versions.
> On 14 Sep 2019, at 16:41, Paul ***@***.***> wrote:
>
> see also https://github.com/proddy/EMS-ESP/wiki/MQTT <https://github.com/proddy/EMS-ESP/wiki/MQTT> on how to use MQTT to control multiple heating circuits.
>
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub <#162>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ANDW447T7JESJOOX3ULDVWLQJTZZNANCNFSM4IGOZDBQ>.
>
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
please find the jabber log until the crash :
(00:00:08.141) ems_parseTelegram: 00 01: 8B
(00:00:08.142) emsuart_tx_buffer: 00 01: 0B 82 02 00 20 EC
(00:00:08.158) ems_parseTelegram: 00 02: 0B 82 02 00 20 EC
(00:00:08.158) echo:telegram: 0B 82 02 00 20 (CRC=EC) #data=1
(00:00:08.390) ems_parseTelegram: 00 02: 90
(00:00:08.395) ems_parseTelegram: 00 02: 10
(00:00:08.415) ems_parseTelegram: 00 02: 89
(00:00:08.425) ems_parseTelegram: 00 02: 09
(00:00:08.440) ems_parseTelegram: 00 02: 8D
(00:00:08.465) ems_parseTelegram: 00 02: 89
(00:00:08.472) ems_parseTelegram: 00 02: 09
(00:00:08.490) ems_parseTelegram: 00 02: 8E
(00:00:08.515) ems_parseTelegram: 00 02: 91
(00:00:08.519) ems_parseTelegram: 00 02: 11
(00:00:08.540) ems_parseTelegram: 00 02: 89
(00:00:08.549) ems_parseTelegram: 00 02: 09
(00:00:08.565) ems_parseTelegram: 00 02: 99
(00:00:08.569) ems_parseTelegram: 00 02: 19
(00:00:08.590) ems_parseTelegram: 00 02: 8F
(00:00:08.615) ems_parseTelegram: 00 02: A1
(00:00:08.619) ems_parseTelegram: 00 02: 21
(00:00:08.639) ems_parseTelegram: 00 02: 92
(00:00:08.664) ems_parseTelegram: 00 02: 89
(00:00:08.672) ems_parseTelegram: 00 02: 09
(00:00:08.689) ems_parseTelegram: 00 02: 89
(00:00:08.698) ems_parseTelegram: 00 02: 09
(00:00:08.714) ems_parseTelegram: 00 02: 89
(00:00:08.724) ems_parseTelegram: 00 02: 09
(00:00:08.739) ems_parseTelegram: 00 02: 89
(00:00:08.749) ems_parseTelegram: 00 02: 09
(00:00:08.764) ems_parseTelegram: 00 02: 8B
(00:00:08.789) ems_parseTelegram: 00 02: 90
(00:00:08.794) ems_parseTelegram: 00 02: 10
(00:00:08.814) ems_parseTelegram: 00 02: 89
(00:00:08.821) ems_parseTelegram: 00 02: 09
(00:00:08.839) ems_parseTelegram: 00 02: 93
(00:00:08.864) ems_parseTelegram: 00 02: 89
(00:00:08.873) ems_parseTelegram: 00 02: 09
(00:00:08.888) ems_parseTelegram: 00 02: 94
(00:00:08.913) ems_parseTelegram: 00 02: 91
(00:00:08.918) ems_parseTelegram: 00 02: 11
(00:00:08.938) ems_parseTelegram: 00 02: 89
(00:00:08.945) ems_parseTelegram: 00 02: 09
(00:00:08.964) ems_parseTelegram: 00 02: 99
(00:00:08.968) ems_parseTelegram: 00 02: 19
(00:00:08.988) ems_parseTelegram: 00 02: 95
(00:00:09.013) ems_parseTelegram: 00 02: A1
(00:00:09.017) ems_parseTelegram: 00 02: 21
(00:00:09.038) ems_parseTelegram: 00 02: 96
(00:00:09.063) ems_parseTelegram: 00 02: 89
(00:00:09.073) ems_parseTelegram: 00 02: 09
(00:00:09.088) ems_parseTelegram: 00 02: 89
(00:00:09.094) ems_parseTelegram: 00 02: 09
(00:00:09.113) ems_parseTelegram: 00 02: 89
(00:00:09.120) ems_parseTelegram: 00 02: 09
(00:00:09.138) ems_parseTelegram: 00 02: 89
(00:00:09.145) ems_parseTelegram: 00 02: 09
(00:00:09.163) ems_parseTelegram: 00 02: 8B
(00:00:09.188) ems_parseTelegram: 00 02: 90
(00:00:09.192) ems_parseTelegram: 00 02: 10
(00:00:09.212) ems_parseTelegram: 00 02: 89
(00:00:09.222) ems_parseTelegram: 00 02: 09
(00:00:09.237) ems_parseTelegram: 00 02: 97
(00:00:09.262) ems_parseTelegram: 00 02: 89
(00:00:09.269) ems_parseTelegram: 00 02: 09
(00:00:09.287) ems_parseTelegram: 00 02: 9C
(00:00:09.312) ems_parseTelegram: 00 02: 91
(00:00:09.316) ems_parseTelegram: 00 02: 11
(00:00:09.337) ems_parseTelegram: 00 02: 89
(00:00:09.346) ems_parseTelegram: 00 02: 09
(00:00:09.362) ems_parseTelegram: 00 02: 99
(00:00:09.366) ems_parseTelegram: 00 02: 19
(00:00:09.387) ems_parseTelegram: 00 02: A4
(00:00:09.412) ems_parseTelegram: 00 02: A1
(00:00:09.416) ems_parseTelegram: 00 02: 21
(00:00:09.436) ems_parseTelegram: 00 02: AC
(00:00:09.461) ems_parseTelegram: 00 02: 89
(00:00:09.469) ems_parseTelegram: 00 02: 09
(00:00:09.486) ems_parseTelegram: 00 02: 89
(00:00:09.495) ems_parseTelegram: 00 02: 09
(00:00:09.511) ems_parseTelegram: 00 02: 89
(00:00:09.521) ems_parseTelegram: 00 02: 09
(00:00:09.536) ems_parseTelegram: 00 02: 89
(00:00:09.546) ems_parseTelegram: 00 02: 09
(00:00:09.561) ems_parseTelegram: 00 02: 8B
(00:00:09.586) ems_parseTelegram: 00 02: 90
(00:00:09.591) ems_parseTelegram: 00 02: 10
(00:00:09.629) ems_parseTelegram: 00 02: 08 00 07 00 03 03 02 02 00 00 00 00 00 00 00 00 00 FF
(00:00:09.630) Boiler -> all, type 0x07, telegram: 08 00 07 00 03 03 02 02 00 00 00 00 00 00 00 00 00 (CRC=FF) #data=13
(00:00:09.810) ems_parseTelegram: 00 01: B4
(00:00:09.835) ems_parseTelegram: 00 01: 89
(00:00:09.845) ems_parseTelegram: 00 01: 09
(00:00:09.860) ems_parseTelegram: 00 01: BC
(00:00:09.885) ems_parseTelegram: 00 01: 91
(00:00:09.889) ems_parseTelegram: 00 01: 11
(00:00:09.910) ems_parseTelegram: 00 01: 89
(00:00:09.917) ems_parseTelegram: 00 01: 09
(00:00:09.935) ems_parseTelegram: 00 01: 99
(00:00:09.939) ems_parseTelegram: 00 01: 19
(00:00:09.960) ems_parseTelegram: 00 01: C4
(00:00:09.985) ems_parseTelegram: 00 01: A1
(00:00:09.989) ems_parseTelegram: 00 01: 21
(00:00:10.009) ems_parseTelegram: 00 01: CC
(00:00:10.034) ems_parseTelegram: 00 01: 89
(00:00:10.040) ems_parseTelegram: 00 01: 09
(00:00:10.059) ems_parseTelegram: 00 01: 89
(00:00:10.066) ems_parseTelegram: 00 01: 09
(00:00:10.084) ems_parseTelegram: 00 01: 89
(00:00:10.092) ems_parseTelegram: 00 01: 09
(00:00:10.109) ems_parseTelegram: 00 01: 89
(00:00:10.117) ems_parseTelegram: 00 01: 09
(00:00:10.134) ems_parseTelegram: 00 01: 90
(00:00:10.139) ems_parseTelegram: 00 01: 10
(00:00:10.159) ems_parseTelegram: 00 01: 91
(00:00:10.163) ems_parseTelegram: 00 01: 11
(00:00:10.184) ems_parseTelegram: 00 01: 89
(00:00:10.189) ems_parseTelegram: 00 01: 09
(00:00:10.209) ems_parseTelegram: 00 01: D4
(00:00:10.234) ems_parseTelegram: 00 01: 89
(00:00:10.241) ems_parseTelegram: 00 01: 09
(00:00:10.258) ems_parseTelegram: 00 01: DC
(00:00:10.283) ems_parseTelegram: 00 01: 99
(00:00:10.288) ems_parseTelegram: 00 01: 19
(00:00:10.308) ems_parseTelegram: 00 01: 89
(00:00:10.318) ems_parseTelegram: 00 01: 09
(00:00:10.333) ems_parseTelegram: 00 01: A1
(00:00:10.338) ems_parseTelegram: 00 01: 21
(00:00:10.358) ems_parseTelegram: 00 01: E4
(00:00:10.383) ems_parseTelegram: 00 01: 89
(00:00:10.390) ems_parseTelegram: 00 01: 09
(00:00:10.408) ems_parseTelegram: 00 01: EC
(00:00:10.433) ems_parseTelegram: 00 01: 89
(00:00:10.441) ems_parseTelegram: 00 01: 09
(00:00:10.458) ems_parseTelegram: 00 01: 89
(00:00:10.467) ems_parseTelegram: 00 01: 09
(00:00:10.483) ems_parseTelegram: 00 01: 90
(00:00:10.487) ems_parseTelegram: 00 01: 10
(00:00:10.507) ems_parseTelegram: 00 01: 89
(00:00:10.514) ems_parseTelegram: 00 01: 09
(00:00:10.532) ems_parseTelegram: 00 01: 91
(00:00:10.537) ems_parseTelegram: 00 01: 11
(00:00:10.557) ems_parseTelegram: 00 01: 99
(00:00:10.562) ems_parseTelegram: 00 01: 19
(00:00:10.582) ems_parseTelegram: 00 01: 89
(00:00:10.591) ems_parseTelegram: 00 01: 09
(00:00:10.607) ems_parseTelegram: 00 01: 8A
(00:00:10.632) ems_parseTelegram: 00 01: 89
(00:00:10.642) ems_parseTelegram: 00 01: 09
(00:00:10.657) ems_parseTelegram: 00 01: 8B
(00:00:10.657) emsuart_tx_buffer: 00 01: 0B 88 02 00 20 BC
(00:00:10.672) ems_parseTelegram: 00 02: 0B 88 02 00 20 BC
(00:00:10.673) echo:telegram: 0B 88 02 00 20 (CRC=BC) #data=1
(00:00:10.697) ems_parseTelegram: 00 02: 08 0B 02 00 73 05 05 00 00 00 00 00 00 00 D7
(00:00:10.698) Boiler -> me, type 0x02, telegram: 08 0B 02 00 73 05 05 00 00 00 00 00 00 00 (CRC=D7) #data=10
Boiler found: Nefit Topline Compact/Buderus GB162 (DeviceID:0x08 ProductID:115 Version:05.05)
(00:00:10.699) emsuart_tx_buffer: 00 01: 0B
(00:00:10.704) ems_parseTelegram: 00 01: 0B
(00:00:10.707) ems_parseTelegram: 00 01: A1
(00:00:10.711) ems_parseTelegram: 00 01: 21
(00:00:10.750) ems_parseTelegram: 00 01: 08 00 07 00 0B 03 02 02 00 00 00 00 00 00 00 00 00 D3
(00:00:10.751) Boiler -> all, type 0x07, telegram: 08 00 07 00 0B 03 02 02 00 00 00 00 00 00 00 00 00 (CRC=D3) #data=13
(00:00:10.931) ems_parseTelegram: 00 01: 89
(00:00:10.940) ems_parseTelegram: 00 01: 09
(00:00:10.956) ems_parseTelegram: 00 01: 8C
(00:00:10.981) ems_parseTelegram: 00 01: 89
(00:00:10.987) ems_parseTelegram: 00 01: 09
(00:00:11.006) ems_parseTelegram: 00 01: 8D
(00:00:11.030) ems_parseTelegram: 00 01: 89
(00:00:11.038) ems_parseTelegram: 00 01: 09
(00:00:11.055) ems_parseTelegram: 00 01: 8B
(00:00:11.056) emsuart_tx_buffer: 00 01: 0B 89 02 00 20 B4
(00:00:11.071) ems_parseTelegram: 00 02: 0B 89 02 00 20 B4
(00:00:11.071) echo:telegram: 0B 89 02 00 20 (CRC=B4) #data=1
(00:00:11.094) ems_parseTelegram: 00 02: 09 0B 02 00 44 02 03 25
(00:00:11.095) 0x09 -> me, type 0x02, telegram: 09 0B 02 00 44 02 03 (CRC=25) #data=3
Device found: BC10/RFM20 Receiver (DeviceID:0x09 ProductID:68 Version:02.03)
(00:00:11.096) emsuart_tx_buffer: 00 01: 0B
(00:00:11.101) ems_parseTelegram: 00 01: 0B
(00:00:11.105) ems_parseTelegram: 00 01: 90
(00:00:11.110) ems_parseTelegram: 00 01: 10
(00:00:11.130) ems_parseTelegram: 00 01: 89
(00:00:11.136) ems_parseTelegram: 00 01: 09
(00:00:11.155) ems_parseTelegram: 00 01: 91
(00:00:11.160) ems_parseTelegram: 00 01: 11
(00:00:11.180) ems_parseTelegram: 00 01: 99
(00:00:11.185) ems_parseTelegram: 00 01: 19
(00:00:11.205) ems_parseTelegram: 00 01: 89
(00:00:11.213) ems_parseTelegram: 00 01: 09
(00:00:11.230) ems_parseTelegram: 00 01: 8E
(00:00:11.255) ems_parseTelegram: 00 01: 89
(00:00:11.264) ems_parseTelegram: 00 01: 09
(00:00:11.280) ems_parseTelegram: 00 01: 8F
(00:00:11.305) ems_parseTelegram: 00 01: A1
(00:00:11.309) ems_parseTelegram: 00 01: 21
(00:00:11.329) ems_parseTelegram: 00 01: 89
(00:00:11.336) ems_parseTelegram: 00 01: 09
(00:00:11.354) ems_parseTelegram: 00 01: 89
(00:00:11.362) ems_parseTelegram: 00 01: 09
(00:00:11.379) ems_parseTelegram: 00 01: 92
(00:00:11.404) ems_parseTelegram: 00 01: 89
(00:00:11.414) ems_parseTelegram: 00 01: 09
(00:00:11.429) ems_parseTelegram: 00 01: 93
(00:00:11.454) ems_parseTelegram: 00 01: 89
(00:00:11.460) ems_parseTelegram: 00 01: 09
(00:00:11.479) ems_parseTelegram: 00 01: 8B
(00:00:11.479) emsuart_tx_buffer: 00 01: 0B 90 02 00 20 7C
(00:00:11.494) ems_parseTelegram: 00 02: 0B 90 02 00 20 7C
(00:00:11.495) echo:telegram: 0B 90 02 00 20 (CRC=7C) #data=1
(00:00:11.540) ems_parseTelegram: 00 02: 10 0B 02 00 56 15 08 5E
(00:00:11.540) 0x10 -> me, type 0x02, telegram: 10 0B 02 00 56 15 08 (CRC=5E) #data=3
Thermostat found: RC35 (DeviceID:0x10 ProductID:86 Version:21.08)
* Setting Thermostat to RC35 (DeviceID:0x10 ProductID:86 Version:21.08)
(00:00:11.542) emsuart_tx_buffer: 00 01: 0B
(00:00:11.547) ems_parseTelegram: 00 01: 0B
(00:00:11.554) ems_parseTelegram: 00 01: 90
(00:00:11.558) ems_parseTelegram: 00 01: 10
(00:00:11.579) ems_parseTelegram: 00 01: 89
(00:00:11.589) ems_parseTelegram: 00 01: 09
(00:00:11.603) ems_parseTelegram: 00 01: 91
(00:00:11.608) ems_parseTelegram: 00 01: 11
(00:00:11.629) ems_parseTelegram: 00 01: 99
(00:00:11.633) ems_parseTelegram: 00 01: 19
(00:00:11.653) ems_parseTelegram: 00 01: 89
(00:00:11.660) ems_parseTelegram: 00 01: 09
(00:00:11.678) ems_parseTelegram: 00 01: 94
(00:00:11.703) ems_parseTelegram: 00 01: 89
(00:00:11.712) ems_parseTelegram: 00 01: 09
(00:00:11.728) ems_parseTelegram: 00 01: 95
(00:00:11.753) ems_parseTelegram: 00 01: A1
(00:00:11.757) ems_parseTelegram: 00 01: 21
(00:00:11.778) ems_parseTelegram: 00 01: 89
(00:00:11.784) ems_parseTelegram: 00 01: 09
(00:00:11.803) ems_parseTelegram: 00 01: 89
(00:00:11.810) ems_parseTelegram: 00 01: 09
(00:00:11.828) ems_parseTelegram: 00 01: 96
(00:00:11.852) ems_parseTelegram: 00 01: 89
(00:00:11.861) ems_parseTelegram: 00 01: 09
(00:00:11.877) ems_parseTelegram: 00 01: 97
(00:00:11.902) ems_parseTelegram: 00 01: 89
(00:00:11.913) ems_parseTelegram: 00 01: 09
(00:00:11.927) ems_parseTelegram: 00 01: 8B
(00:00:11.928) emsuart_tx_buffer: 00 01: 0B 91 02 00 20 74
(00:00:11.943) ems_parseTelegram: 00 02: 0B 91 02 00 20 74
(00:00:11.943) echo:telegram: 0B 91 02 00 20 (CRC=74) #data=1
(00:00:12.014) ems_parseTelegram: 00 02: 11 0B 02 00 47 02 00 7C
(00:00:12.014) 0x11 -> me, type 0x02, telegram: 11 0B 02 00 47 02 00 (CRC=7C) #data=3
Device found: WM10 Switch Module (DeviceID:0x11 ProductID:71 Version:02.00)
(00:00:12.016) emsuart_tx_buffer: 00 01: 0B
(00:00:12.021) ems_parseTelegram: 00 01: 0B
(00:00:12.027) ems_parseTelegram: 00 01: 90
(00:00:12.031) ems_parseTelegram: 00 01: 10
(00:00:12.052) ems_parseTelegram: 00 01: 89
(00:00:12.062) ems_parseTelegram: 00 01: 09
(00:00:12.077) ems_parseTelegram: 00 01: 91
(00:00:12.081) ems_parseTelegram: 00 01: 11
(00:00:12.102) ems_parseTelegram: 00 01: 99
(00:00:12.106) ems_parseTelegram: 00 01: 19
(00:00:12.126) ems_parseTelegram: 00 01: 89
(00:00:12.134) ems_parseTelegram: 00 01: 09
(00:00:12.151) ems_parseTelegram: 00 01: 98
(00:00:12.263) ems_parseTelegram: 00 01: 18 00 AF 00 83 00 09 00 00 B5
(00:00:12.264) 0x18 -> all, type 0xAF, telegram: 18 00 AF 00 83 00 09 00 00 (CRC=B5) #data=5
(00:00:12.451) ems_parseTelegram: 00 01: 18
(00:00:12.475) ems_parseTelegram: 00 01: 89
(00:00:12.484) ems_parseTelegram: 00 01: 09
(00:00:12.500) ems_parseTelegram: 00 01: A0
(00:00:12.525) ems_parseTelegram: 00 01: A1
(00:00:12.530) ems_parseTelegram: 00 01: 21
(00:00:12.568) ems_parseTelegram: 00 01: 08 00 07 00 0B 03 03 02 00 00 00 00 00 00 00 00 00 B7
(00:00:12.569) Boiler -> all, type 0x07, telegram: 08 00 07 00 0B 03 03 02 00 00 00 00 00 00 00 00 00 (CRC=B7) #data=13
(00:00:12.749) ems_parseTelegram: 00 01: 89
(00:00:12.756) ems_parseTelegram: 00 01: 09
(00:00:12.774) ems_parseTelegram: 00 01: A8
(00:00:12.799) ems_parseTelegram: 00 01: 89
(00:00:12.808) ems_parseTelegram: 00 01: 09
(00:00:12.824) ems_parseTelegram: 00 01: B0
(00:00:12.849) ems_parseTelegram: 00 01: 89
(00:00:12.859) ems_parseTelegram: 00 01: 09
(00:00:12.874) ems_parseTelegram: 00 01: 8B
(00:00:12.874) emsuart_tx_buffer: 00 01: 0B 97 02 00 20 44
(00:00:12.889) ems_parseTelegram: 00 02: 0B 97 02 00 20 44
(00:00:12.890) echo:telegram: 0B 97 02 00 20 (CRC=44) #data=1
(00:00:13.123) ems_parseTelegram: 00 02: 90
(00:00:13.127) ems_parseTelegram: 00 02: 10
(00:00:13.179) ems_parseTelegram: 00 02: 08 00 18 00 07 01 8A 00 00 00 00 00 60 01 1B 02 45 01 A7 00 00 0A 30 48 00 CB 00 00 00 22
(00:00:13.180) Boiler -> all, type 0x18, telegram: 08 00 18 00 07 01 8A 00 00 00 00 00 60 01 1B 02 45 01 A7 00 00 0A 30 48 00 CB 00 00 00 (CRC=22) #data=25
(00:00:13.372) ems_parseTelegram: 00 01: 91
(00:00:13.376) ems_parseTelegram: 00 01: 11
(00:00:13.397) ems_parseTelegram: 00 01: 98
(00:00:13.402) ems_parseTelegram: 00 01: 18
(00:00:13.447) ems_parseTelegram: 00 01: 08 00 34 00 3D 02 45 02 45 21 00 00 03 00 00 98 EC 00 15 49 00 80 00 D4
(00:00:13.448) Boiler -> all, type 0x34, telegram: 08 00 34 00 3D 02 45 02 45 21 00 00 03 00 00 98 EC 00 15 49 00 80 00 (CRC=D4) #data=19
(00:00:13.646) ems_parseTelegram: 00 01: B8
(00:00:13.671) ems_parseTelegram: 00 01: 89
(00:00:13.677) ems_parseTelegram: 00 01: 09
(00:00:13.696) ems_parseTelegram: 00 01: C0
(00:00:13.721) ems_parseTelegram: 00 01: 99
(00:00:13.725) ems_parseTelegram: 00 01: 19
(00:00:13.745) ems_parseTelegram: 00 01: 89
(00:00:13.754) ems_parseTelegram: 00 01: 09
(00:00:13.771) ems_parseTelegram: 00 01: A1
(00:00:13.775) ems_parseTelegram: 00 01: 21
(00:00:13.795) ems_parseTelegram: 00 01: C8
(00:00:13.820) ems_parseTelegram: 00 01: 89
(00:00:13.831) ems_parseTelegram: 00 01: 09
(00:00:13.845) ems_parseTelegram: 00 01: D0
(00:00:13.870) ems_parseTelegram: 00 01: 89
(00:00:13.877) ems_parseTelegram: 00 01: 09
(00:00:13.895) ems_parseTelegram: 00 01: 89
(00:00:13.903) ems_parseTelegram: 00 01: 09
(00:00:13.920) ems_parseTelegram: 00 01: 8B
(00:00:13.920) emsuart_tx_buffer: 00 01: 0B 98 02 00 20 3C
(00:00:13.935) ems_parseTelegram: 00 02: 0B 98 02 00 20 3C
(00:00:13.936) echo:telegram: 0B 98 02 00 20 (CRC=3C) #data=1
… On 14 Sep 2019, at 18:11, susisstrolch ***@***.***> wrote:
I‘d suggest ‚set log j‘ to get an idea where it happens...
Sent by mobile device
> Am 14.09.2019 um 17:26 schrieb lmdecroos ***@***.***>:
>
> Thanks for updating the MQTT wiki, but I'm still suffer to get my thermostat / HC recognised in version 1.9.x
>
> With the standard EMS protocol, both my boiler and HC are recognised in version 1.8.3, but when using version 1.9.x the EMS gateway crashes at startup while polling the bus.
> The gateway hangs every time on : Sending read of type 0x02 to 0x18, telegram: 0B 98 02 00 20 (CRC=3C) and reboots itself afterwards, see my entry from 11th September.
> I tested this messages in version 1.8.3, and then the 18.3 EMS gateway crashes also.
>
> Can you advise where I have to look in the source code for the initiation and startup process, so that I can troubleshoot by check the differences between both versions.
>
>
> > On 14 Sep 2019, at 16:41, Paul ***@***.***> wrote:
> >
> > see also https://github.com/proddy/EMS-ESP/wiki/MQTT <https://github.com/proddy/EMS-ESP/wiki/MQTT> on how to use MQTT to control multiple heating circuits.
> >
> > —
> > You are receiving this because you were mentioned.
> > Reply to this email directly, view it on GitHub <#162>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ANDW447T7JESJOOX3ULDVWLQJTZZNANCNFSM4IGOZDBQ>.
> >
>
> —
> You are receiving this because you are subscribed to this thread.
> Reply to this email directly, view it on GitHub, or mute the thread.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub <#162>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ANDW442USL5RN4VPJNKPEGDQJUEJ7ANCNFSM4IGOZDBQ>.
|
|
Please create a new GitHub issue for the reboot problems. From the log I see the devices are detected correctly so something else is causing the crash, either the MQTT or the Event Log. |
|
I have version 1.9.1b3. Additionally, I noticed that the web interface is very unstable (hangs) |
|
@majdzik84 all heating circuits should be detected and shown. What's strange is that you don't get any listed under the 'Thermostat stats' page? The code picks up messages from telegram types 0x3E (HC1), 0x48 (HC2), 0x52 (HC3) and 0x5C (HC4) I can't test when I make these changes and do my best to simulate what it would look like on the multitude of thermostat models so any test data would be helpful. Even better are code changes ;) |
|
below I am sending a log - maybe it will be helpful in something |
|
what I can see is HC1 = 10 0B 3E 00 00 00 00 7D 00 00 00 00 00 00 00 00 00 11 05 04 which tells me Is this in line with what you expect? |
proddy
added a commit
that referenced
this issue
Sep 17, 2019
|
the thermostat controls the HC2 circuit (RC35) the current temperature is correct but the setpoint temp. should not show 0.0C. automatic mode was enabled and should be fixed in this version. |
|
It seems as long the subtopics are not complete between HC1 and HC2, the data fro HC2 comes through
once the EMS gateway has all values ( subtopics) for both HC’s that only the value of HC1 is taken in account
the first 3 messages after a restart ( and filtered on HC2)
{"hc1":{"daytemp":19,"nighttemp":15,"holidayttemp":17,"heatingtype":1,"mode":"auto"},"hc2":{"daytemp":18,"nighttemp":13.5,"holidayttemp":17,"heatingtype":1,"mode":"night"}}
{"hc1":{"seltemp":19,"currtemp":20.8,"daytemp":19,"nighttemp":15,"holidayttemp":17,"heatingtype":1,"circuitcalctemp":5,"mode":"auto"},"hc2":{"daytemp":18,"nighttemp":13.5,"holidayttemp":17,"heatingtype":1,"mode":"night"}}
{"hc1":{"seltemp":19,"currtemp":20.8,"daytemp":19,"nighttemp":15,"holidayttemp":17,"heatingtype":1,"circuitcalctemp":5,"mode":"auto"},"hc2":{"seltemp":13.5,"currtemp":19.6,"daytemp":18,"nighttemp":13.5,"holidayttemp":17,"heatingtype":1,"circuitcalctemp":5,"mode":"night"}}
on the next update all values are published, but only the values from HC1 are coming through
… On 13 Oct 2019, at 18:50, Proddy ***@***.***> wrote:
yes I'm seeing those too, its kinda random and I think they've always been there but I've suppressed the warnings. I'm also looking into this. The MQTT is still sent.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub <#162>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ANDW44YKJIVZZVR5FCPREULQONGVHANCNFSM4IGOZDBQ>.
|
|
sorry, not sure I understand. What is happening and what is the expected behaviour ? |
|
When looking at MQTT explorer, after an EMS gateway reboot the MQTT messages contains {"hc1":{“day…. and ,"hc2":{“dayt ….
But once all values for HC1 and HC2 are published, the MQTT receiver seems to be confused as it received 2 times the values ( one for HC1 another for HC2) and it takes only the one for HC1 in account
it seems that the MQTT message can’t handle 2 times the values in the same topic
… On 13 Oct 2019, at 21:02, Proddy ***@***.***> wrote:
sorry, not sure I understand. What is happening and what is the expected behaviour ?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub <#162>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ANDW44ZZSQMY25ASG2MQAZTQONWE3ANCNFSM4IGOZDBQ>.
|
|
still confused, sorry! Is the payload on the |
|
Yes, payload thermostat data in the EMS gateway seems to be correct ( at least it contains all details for both HC’s) , but the MQTT explorer is not able to interpreet it correct.
it’s understand only the values for HC1, it ignores the values for HC2
Only on the first (3) messages after a reboot, when it the EMS is still missing some data, the values of HC2 are in the message received / interpreted by MQTT explorer
message 1 :
{"hc1":{"seltemp":19,"currtemp":20.8,"daytemp":19,"nighttemp":15,"holidayttemp":17,"heatingtype":1,"circuitcalctemp":5,"mode":"auto”}}
message 2 :
{"hc1":{"seltemp":19,"currtemp":20.8,"daytemp":19,"nighttemp":15,"holidayttemp":17,"heatingtype":1,"circuitcalctemp":5,"mode":"auto"},"hc2":{"daytemp":18,"nighttemp":13.5,"holidayttemp":17,"heatingtype":1,"mode":"night”}}
message 3 :
{"hc1":{"seltemp":19,"currtemp":20.8,"daytemp":19,"nighttemp":15,"holidayttemp":17,"heatingtype":1,"circuitcalctemp":5,"mode":"auto"},"hc2":{"seltemp":13.5,"currtemp":19.6,"daytemp":18,"nighttemp":13.5,"holidayttemp":17,"heatingtype":1,"circuitcalctemp":5,"mode":"night"}}
message 4 and later
{"hc1":{"daytemp":19,"nighttemp":15,"holidayttemp":17,"heatingtype":1,"mode":"auto”}}
so from message 4 onwards all the details of HC2 are missing on the MQTT receiver side
… On 13 Oct 2019, at 21:28, Proddy ***@***.***> wrote:
thermostat_data correct
|
|
ahh, found the error. very silly of me. I'll do a commit soon. |
proddy
added a commit
that referenced
this issue
Oct 13, 2019
|
well done, seems to be fixed
{"hc1":{"seltemp":19,"currtemp":21,"daytemp":19,"nighttemp":15,"holidayttemp":17,"heatingtype":1,"circuitcalctemp":5,"mode":"auto"},"hc2":{"seltemp":13.5,"currtemp":19.9,"daytemp":18,"nighttemp":13.5,"holidayttemp":17,"heatingtype":1,"circuitcalctemp":5,"mode":"night”}}
I will contact bbqkees and ask him to update his plugin
… On 13 Oct 2019, at 21:59, Proddy ***@***.***> wrote:
ahh, found the error. very silly of me. I'll do a commit soon.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub <#162>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ANDW444DTJTPVJNWLLESRCTQON4ZHANCNFSM4IGOZDBQ>.
|
|
ok closing this issue for now. |
|
1.9.2b9 I noticed that setpoint temperature again does not give the correct value in auto-day, auto-night mode. Example: When changing from OFF (night) mode to auto mode it still shows off-night temperature instead of auto-day. Should now show 22C (auto-day) |
|
oh no, this again. Did it ever work? The logic is just too difficult to figure out as 1) I don't own an RC35 and 2) I never really understood what auto-day and auto-night really means. Do you think you could take a look at code and with your example telegrams do a PR ? Otherwise we'll just be going back and forth for weeks and I don't have the time. |
|
unfortunately I am not a programmer. I don't know how to do PR :( A few versions ago (i thing 1.9.1b11 ) I have the impression that in automatic mode it just jumped between day-temp and night-temp. So it's day-temp and night-temp - automatic mode just switches these temperatures (auto-day - shows day temp) and in the evening auto-night (shows nighttemp) EDIT: |
|
I can do the programming, I just need someone to create the rules. The logic now is in
In your examples the data blocks look like For 0x3E (HC1): For 0x48 (HC2): can you help define what it should be? |
|
Probably, before I get the ideas of bytes, etc. it will pass a little :) Auto-night - RC35 Auto-day - RC35 Auto-Day- (change in HA) Auto-day (change in HA from night mode) < incorrect setpoint (its still night temp) Auto-day (change in HA from day mode (heat)) Auto-night(change in HA from day mode(heat)) < incorrect setpoint (its still day temp) |
|
In all those examples, the setpoint temperature is 0.0C. I've highlighted them below: Auto-night - RC35 Auto-day - RC35 Auto-Day- (change in HA) Auto-day (change in HA from night mode) < incorrect setpoint (its still night temp) Auto-day (change in HA from day mode (heat)) Auto-night(change in HA from day mode(heat)) < incorrect setpoint (its still day temp) But there's another byte we could read adjacent to the setpoint. I'm not sure what it is. I've listed the values below. Can you see if this matches anything you're seeing? Auto-night - RC35 Auto-day - RC35 Auto-Day- (change in HA) Auto-day (change in HA from night mode) < incorrect setpoint (its still night temp) Auto-day (change in HA from day mode (heat)) Auto-night(change in HA from day mode(heat)) < incorrect setpoint (its still day temp) |
|
Yes.I think it's current room temperature |
|
From each of the examples I need to know what the expected setpoint values should be, so I can hunt them down in the telegrams. |
|
I did a few tests with 1.9.1 release and 1.9.2b10 and all temperatures are correct.
when using 1.9.1 it takes up to 2 minutes before the change in mode ( day/ night/ auto) are reflected.
when using 1.9.2b10 it takes up to 5 minutes or more
even after 20 minutes i have only :
Thermostat stats:
Thermostat: RC20F (ProductID:93 Version:02.00)
Thermostat time is 18:05:59 16/10/2019
Heating Circuit 1
Current room temperature: 19.6 C
Setpoint room temperature: 19.0 C
Heating Circuit 2
Current room temperature: 18.3 C
Setpoint room temperature: 13.5 C
Mode is set to night
… On 16 Oct 2019, at 17:37, majdzik84 ***@***.***> wrote:
Yes.I think it's current room temperature
<https://user-images.githubusercontent.com/31352476/66934937-8c5aac00-f03b-11e9-91f9-50f3b1d7a915.png>
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub <#162>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ANDW447P2LB2ZJHQPZNGM2TQO4YJ5ANCNFSM4IGOZDBQ>.
|
|
Of course, the temperatures work correctly.
After thinking, I think that it is easier to control the thermostat, e.g. in Home assistant by simply setting the day or night temperature because the auto mode switches them on at the appropriate times. I think Proddy once inserted a dependency. If in auto mode set temperature = 0.0C show day temp or night temp (depending on rc35 is in auto-day or auto-night mode). The problem is that if the night mode 20C switched to auto mode (which is currently in daytime auto mode) then the temperature does not change to 22C (day temp) but remains at 20C. I hope this clarifies things a little. |
|
I don't know what it is caused by, but I noticed that there are times when all switches work properly but it also happens that the temperatures are not updated. |
|
I should be able to find the auto-day and auto-night modes. They must be in 0x3D (HC1) or 0x47 (HC2) if you could send along some examples. |
|
Auto-Day (temp. day 22C) Auto-Night (temp. night 20C)
|
|
lol, they're identical so its not in that telegram! |
|
yes, they are identical - to be sure I checked 2 times |
|
closing. |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
I'm pretty new on this fora and starting to explore the possibilities of the EMS-ESP.
On top, I'm a Home Assistant (HA) user in order to control my home domotica.
I was very enthusiastic to read on the fora that it is possible to control the 2 heating circuits.
I'm using HC1 for radiators in the bedrooms & bathroom (level 1), HC2 as floor heating (level 0).
Is there a possibility to control both Heating Circuits at the same time with MQTT?
Meaning, having two thermostat control systems in the Home Assistant GUI.
Now you need to switch all the time between the Heating Circuits in order to read out the temperature and the heating settings.
The text was updated successfully, but these errors were encountered: