unknown devices (Junkers FR50) #224
Comments
proddy
added
enhancement
|
Thanks @oorotor for reporting these devices. I've added the FR50 and made it use the same logic behavior as the FR10 although I can't guarantee it will work. It's in the latest dev build so have a try and if you're not getting correct values back from the thermostat we'll need to deep dive into the telegrams. The 0x09 device is the Junkers controller which was added earlier too the dev builds. I'm now doing nightly builds of the development/beta builds if you're not comfortable compiling and building the firmware yourself. As for the MQTT, this is normal behaviour. As explained in the wiki MQTT topics are only published if the data has changed. I can see in your case (and also some others which use time-based data stores like innoDB and grafana) it would be more appropriate to always send the data. I could make this an additional flag? Something like |
|
I added it anyway. Was a small change. 1.9.4b1 |
|
I tested the 1.9.4b2 version, the publish_always option is working fine for me, but after a few hours I'm faced with a reported issue of disconnected mqtt #204 (my findigs are documented in issue #204). Regarding the FR50 device: |
|
for the web interface modes, does it show correct when you type |
|
On telnet it is shown as "Mode is unknown". I analysed the 6F-type message on the EMS-bus, it looks like there are two modes transmitted: example message: the 7th byte (here: 03) stands for the day/night mode: the 8th byte (here: 02) stands for the auto/manual mode: I saw in the code, that for other thermostats (e.g. RC35) there is only one mode (auto, night, day), so i guess it's a little bit more effort to add two modes instead. |
|
ok, I'll see if I can add this to the code |
|
can you check if the correct modes (manual/auto) and day/night are shown? |
|
@proddy For these model as well as the RC35, modes are working like that : On some others thermostats, like RC300, there are only 2 modes : auto and manual. is that help ? |
|
@moustic999 could you see if its correct for RC35? I can only check with my RC20 that has off, manual and auto. |
|
@proddy: Thermostat stats: On the webpage, "mode" with "undefined" is displayed and no "day mode". Via MQTT it seems that no mode (mode nor day mode) is transmitted. |
|
oops, forgot some code. try the new build if you can |
|
Now the modes (daymode and mode) are displayed correctly via telnet (daymode is not transmitted via mqtt or shown on webpage) - tested with 1.9.4b7. I just recognized that there is another "day mode" (I was wondering why the day mode byte has no byte=01), so mode "byte=01" is the "AntiFreeze-Mode" (maybe similar to Holiday-Mode?), in this mode the selTemp is set to 5°C and cannot be changed. the 7th bytestands for the day/night mode: the 8th byte stands for the auto/manual mode: |
|
@oorotor I'm not sending the daymode via MQTT. I didn't think it would be useful. But can easily add. Also the modes on the Buderus RCs use bits to determine the modes. Are you sure the values 1,2 and 3 are not bit masks for something else? @moustic999 With the RC35 I thought there was also a summer mode which is a different byte. |
|
@proddy just wanted to inform, that i have updated to 1.9.4b13 today, and afterwards the mode and day mode is not listed correctly anymore with the FR50, also the setpoint room temperature is not correct anymore. downgraded to 1.9.4.b9 again and it seems to work fine with this version again. 1.9.4b9 1.9.4.b13 |
|
ok, thanks for reporting. I'll take a look |
|
made a change, not sure if it'll fix it. Can you test? |
|
Yes, with 1.9.4b14 it is working again: But in this version it seems that i have some issues with the webinterface, e.g. there was no password popup and therefore i was not able to login to the webinterface for several minutes after restart (also after poweroff), also the webinterface seems to stop working after some time. With telnet all seems to work fine ans also the mqtt messages are send. |
|
yes, known issue with the web interface. I'm trying to find what caused it but its difficult. I suspect memory problems somewhere. Can I close this issue? |
|
Yes you can close this issue! |
Hi,
first of all: great project: I'm using it with bbqkees EMS-ESP Gateway. But I have a few questions:
Due to a message in a telnet output, i would like to post following unknown devices, maybe it is possible to support them in the future?
unknown? (DeviceID:0x10 ProductID:147 Version:18.02) --> This should be my Junkers FR50
unknown? (DeviceID:0x09 ProductID:95 Version:35.00) --> ??? this Device has the same version and ProductID as my boiler Bosch Condens 2500/Buderus Logamax GB062/Junkers (DeviceID:0x08 ProductID:95 Version:35.00), but i don't know the which device this is.
fhem is running on a raspberry pi with an MQTT broker, but as soon as i activate the TX in the EMS-ESP webinterface, the boiler data seems to be send not peridically (missing mqtt messages in fhem for more than a few hours (blue region in screenshot), as soon as TX is disabled the mqtt messages are send periodically (orange region in screenshot). I guess this is a misbehaviour, isn't it?
Here are some more data:
Used EMS-ESP version: 1.9.3
Used EMS-ESP Gateway: bbqkees hardware version V1.3 with a generic Wemos D1 Mini V2 type ESP8266
Thanks for the support and the development of this tool!
The text was updated successfully, but these errors were encountered: