-
-
Notifications
You must be signed in to change notification settings - Fork 100
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
Timer processing in RC310 #1594
Comments
Oh, the heating timer for RC300 are 0x1C3-ff, and 0x349-ff. with mode instead of temperature setting. We have to split RC300 - RC310 - BC400. But product-id 158 includes RC300 and RC310, maybe second identifier (unknown). But as mentioned in the lot of discussions before, i don't know how we get that much data in ram and mqtt. |
For the holiday modes check #275. Same problem with a lot of entities. The RC35 is dfferent, it's also 42 entries, but each has day, time, mode stored, We can set all 42 to monday, or 1.entry to Tu, second to monday, 3rd not set, 4th to mo, etc. The RC3x0 have groups with 6 entries for mo, 6 for tu, etc. To index them makes no sense, or count 0-5 for each day. Don't know how to manage. Im thinking of store the raw telegram and generate a program json on api command (and maybe as own mqtt topic). We need to modify the api to forward the json to command. For web page this also can not be an entity in the thermostat section, it need a own editor page. |
what shall we do here @MichaelDvP ? |
I don't have these features on my thermostat so not sure how to proceed. I'll remove this issue from the backlog. |
I am using a Buderus gas boiler with RC310 thermostat and 2 heating circuits I can decode 4 switchTimes per hc. For dhw there are 2 switchPrograms: The heating circuits can be set to use levels (eco/comfort) or absolute temps per switchTime. The switch is done by the entity hcx/switchprogmode for each heating circuit between levels and absolute (temps). switchProgram A: hc1 telegrams level/temps are: 01C3 / 0583 and hc2: 01C4 / 0584 Within #1934 long custom entities in raw are now realized and could be used to maintain the long 84 bytes telegrams. Since quite some time I implemented this in my ioBroker adapter in read/write mode creating the same JSON-objects as the original km200 gateway does. But I needed to implement the right timing for getting the long telegrams and writing them back. |
Each switchProgram has 6 switchTimes per day, 42 switchTimes per week combined with 42 values. |
@tp1de Please use the ems-esp notation for telegram-types. e.g. 0x2FF for dhw1. Thanks. Can you confirm the value order: switchtime 1/2 is selected by program, 0x2B9, offset 11 We can read the whole telegram in ram and generate a json on API command. for RC300 i think the json should look
For commands we can use the same json structure ans json object in value field. But i have no idea
We need a complete concept before starting to code. |
EMS+ and EMS2.0 switchPrograms (For me RC310 and Moduline 2050) 1st step is to select the right telegram type defined by reading the new entities switchprogmodes. hc1 - Mode A level 02C3 and absolute temps 0683 (A == program(1)) hc2 - Mode A level 02C4 and absolute temps 0684 (A == program(1)) dhw1 - Mode A 02FF Each telegram has a length of 84 bytes: Telegram structure of one day looks like this with 2 active switchpoints: P1: time of 1st sp: unit 15 minutes --> 0x14 = 20 *15 = 300 minutes = 05:00 hours P2 are either levels or absolute temps depending on type. Valid for hc and dhw: Levels: "FF": "on" / "03": "comfort" / "02": "high" / "01": "eco/low" / "00": "off" |
km200 API JSON uses time in minutes: |
Within ioBroker I write times: |
I think we do not need the index 01, 02 etc ... in JSON Important: Any change in switchprogmode will require to re-read different telegram type for hc switchprogram. |
The API version with JSON will deliver the similar data object compared to the original Bosch API. At the end JSON structure is not nice to manipulate - neither in ioBroker nor in HA. |
Ah, ok, first time, second mode. (RC35 have reverse order).
If it is not ordered and we want to skip all unset points, we need the number to edit/delete a position. Or we always have to publish/write all unset values.
Does this affect all? Is it really possible to set a cirulation pump to "comfort", or heatingscircuit to "on"?
Again: is there a limit? Is it possible to set temp to 3 (1.5°C) or 0xFF (127,5°C)? Or can we use the number to show mode for FF, 3, 2, 1, 0 and temp for all other values. |
I have never seen non-ordered telegrams. An index is not necessary and is not used within original Bosch API
I do always publish a full day if changed (12 bytes including unset points) - So max 7 telegrams
Decoding for reading telegram is as defined. But possible enum values for writing are:
Minimum temp is 5°C (off) and maximum is 30°C - the same for manual hc values. Only used for absolute temp telegrams. |
Upps, added the missing register/fetch for the telegrams in 3.7.0-test32 |
I implemented a prototype to manage EMS2.0 and EMS+ switchPrograms within Home Assistant using the HACS Scheduler compoment and Node-Red. This solution uses raw hex telegrams send / read by MQTT. It works fine, but was quite tricky for my RC310 thermostat. I wrote a document about my findings during this process and some analysis I have done on my original Bosch / Buderus gateway. |
I've updated the test build https://github.com/MichaelDvP/EMS-ESP32/releases/tag/test
the switchtime1/2 depends on setting of hc1/switchprogmode. I have not tested writing yet, the implementation is to send a single time in one command as json: Also mqtt is not implemented. I think of an extra topic |
I installed your testbuild. 1st test (read) is ok. Writing should be per day with up to 6 switchTimes. How do you indicate otherwise deleted switchTimes? ... and may I repeat my recommandation to name the entities switchprograms. The switchtimes are the times to switch within... |
Ok
Does not work with RC20, RC30 and RC35 where day is coded and can be anywhere in the 42 data, Then i have to write all 42 at once.
Reading: values are ignored, writing with
We have translated word I've updated, setting should work now. |
I still get some errors, but much less than before. |
Please add a log, are the broadcast responses from thermostat now on the same offset as sended?
I don't think so, Emsesp sends only when the master polls, there is no other timing possible. |
Could you please check your code another time. The telegrams do not look right for me: 9/8/2024, 12:44:26 PM | 0B 10 FF 42 01 C3 01 FF 01 FF 01 FF 03 16 01 58 01 FF 01 FF 01 FF 01 FF 3B I tested with sending raw telegrams - each telegram 2 days = 24 bytes of data. Send by mqtt. EDIT: Wait time between commands > 500msec is not ok anymore. Sometimes yes - but otherwise not. |
I think you have picked a intermediate buggy version that was only a few minutes online. Murphys law. |
These are the telegrams when I send raw using your last version: 9/8/2024, 7:13:35 PM | 10 00 FF 3C 01 C3 03 16 01 56 01 FF 01 FF 01 FF 01 FF 03 16 01 56 01 FF 01 FF 01 FF 01 FF 87 and these are the telgrams when I send to json: 9/8/2024, 7:20:35 PM | 10 00 FF 3C 01 C3 03 16 01 56 01 FF 01 FF 01 FF 01 FF 03 16 01 56 01 FF 01 FF 01 FF 01 FF 87 |
Checked again. Your log shows: And now look at this commit: MichaelDvP@1be2eea This is not the same software. |
I took from here |
I've made a commit only to update version, so you can check if you have the latest version installed.
This was a test with 3.7.0.test34 from my github. (not compiled here). |
Sorry Michael, this is difficult for me to understand. |
My gateway crashed this morning again and lost wifi connection. Edit: I recognized that the wifi disconnect is due to protected management frames pmf on wifi, which was activated in my fritzbox mesh master. This has been activated for a long time. |
@MichaelDvP
In both cases the post commands are executed and the switchprograms are changed. |
Seems the moduline does not like the 24bytes telegrams, no error for the 12byte part. Let's try to send 12byte telegrams. RC310 is still test34 with 22 byte. I think you need to clear browser cache before updating, There were some changes in update-code of dev34 that i've merged to keep up to date with the dev. |
Does not make it better: |
Doing changes on moduline 2050 for mo-fr sends this telegrams: 9/10/2024, 3:51:35 PM | 18 00 FF 30 01 C3 03 18 01 1A 03 FF 01 FF 03 FF 01 FF 3D |
Doing changes on RC310 using the cloud app and the gateway for monday and then copying to all other days sends this telegrams: Copy Monday to other days: Monday changes: |
Aha, a complete log, so i can see the context. There is a issue with tx to the master , the master echo is incomplete (one byte too long). Try another tx-mode. |
I tried all TX modes. They are all worse compared to EMS. Moduline is a EMS 2.0 thermostat. |
repeated wrong master echos that shows different receive from sending (in this case an extra byte after crc): |
I agree that this is a timing problem. I tested with sending raw telegrams per days - so 7 telegrams without delay: (1) moduline 2050 3.txt In (1) there are a lot of errors and more other telegrams send by thermostat And it can be recognized that the send commands are processed in reverse order - the last one first. I do not think that this a cabeling problem. (ems-esp connected by service jack and thermostat with 5 m cable) |
Does your boiler use buderus or ht3 protocoll? You'll find it in support info.
Yes, all tx messages are queued and waiting for the master poll. The periodic reads go to end of queue, writes go to top of queue to be send first. If you queue many writes each new goes to top and is sended out first. |
The boiler is a Netfit Trendline II from Bosch. It uses the EMS protocoll. |
I have the same boiler..the Dutch Nefit variant, but a Trendline II CW5. Can I help test something? |
I've already figured out that it's buderus protocoll. The @proddy Do you have seen such effects on writing something to thermostat (i know you have RC20, but it's also a write to device 0x18). |
No I'm not seeing that here on my old RC20/Moduline 300 - adjusting the Thermostat's |
The moduline 2050 supports the ems protocol and as well open therm. |
No. And as explained comparing the two logs moduline 2050 3 and 4 you can see, that under certain conditions the 7 switchtimes writes work without any appended byte as well. It is a matter of other telegrams send inbetween. (total traffic during processing the changes) It is a guess: Does the appended byte indicate that the telegram should be resend or that the telegrams is stored and not written immediately but delayed ....?? |
I tested your build, saw the |
Oh,bad. have you sent the command direct after starting before the telegram was read?. I will add a check for this.
Only for RC300, i have no telegram data for RC20, just a notice about timer telegram typeid. For RC20_N i don't know the timer-telegram(s).
No, the thermostat also gets the wrong bytes appended and answers with a "not-ack"-byte. It's something from the busmaster. |
I do have difficulties to interprete the consequences of errors when writing the switchtimes. Last Tx Write operation failed after 3 retries. Ignoring request:0B 18 FF 00 01 C3 03 16 01 58 03 FF 03 FF 03 FF 03 FF I would expect that changes are not written. But this not the case. See log: |
Discussed in #1593
Originally posted by Nxtway January 30, 2024
ems-esp supports timer processing of the RC35, #979
Could these functionality also implemented for the RC310, please ?
The type-id's in RC310 are:
circulation timer: thermostat(0x10) type(0x0309) | ON - FF | OFF - 00
warm water timer: thermostat(0x10) type(0x02FF) | COMFORT - 02 | ECO - 01 | OFF - ??, maybe 00
heating timer 1: thermostat(0x10) type(0x0683)
heating timer 2 thermostat(0x10) type(0x068D)
Log files attached:
WW_timer.txt
circulation_timer.txt
heating_timer1.txt
heating_timer2.txt
An additional improvement might be the holiday timer, but I didn't find the type-id up to now.
The text was updated successfully, but these errors were encountered: