Somebody tried to run BSB-LAN as room unit?

[dukess]

...connecting 1-2 temperature sensors to board and adding code for sending INF messages with current temp every 60 seconds.

[fredlcore]

Yes, there is a project that does that, I think @1coderookie linked to it in the manual somewhere?

[fredlcore]

And there are others like me which use MAX! or Homematic thermostats to send room and setpoint temperatures.

[hacki11]

Also using homematic thermostat and a little script in iobroker

[dukess]

To clarify idea: if there is a BSB-LAN and a temperature sensor, I want to make the device pretend to be RGT 2 (3), so that it sends information about the temperature in the rooms to the heater. The heater controls the corresponding circuits. Temperature sensor ID can be set via the program number. I am not interested in displaying status information on any screen, since the web interface is available.

It will be interesting to include in the main branch of program?

[1coderookie]

Imho: Sure, include it! Why not!?! It's even more functionality, someone could/would use it for sure! :)

[fredlcore]

Well, that's what we use BSB_lan_custom.h for: You can query the sensor and then send the value to parameter 10001/2/3. The example code does something similar. Or do you mean something else?

[dukess]

Thanks, this example suits me.

[dukess]

@fredlcore Last question for today: should i temporary change own address to RGT1-3 for properly sending INF messages?

[fredlcore]

I think that @1coderookie knows this better, I have only one HC and I'm not sure if the sender can be any ID or has to match RGT1/2/3 for the INFs to have an effect.

[1coderookie]

That's something which isn't really clear yet. In general, the RGT has to match the HC to have an effect - this is how it works with the 'real' room units. But we never could test and never had someone test this for us, if a room temp coming from 0x42 has the same effect on (e.g.) HC2 as a room temp coming from RGT2.

[fredlcore]

Hm, if that was true, how would one set the room temperature for HC3/P? AFAIK, there is no RGT3, or is there?

[1coderookie]

[Correct, there is no dedicated "use as RGT3/P only"-setting within the RGTs] -> that's WRONG! There IS a setting "Usage as room unit 3/P"! Just discovered it right now, I'm checking the telegrams..

As I said, it's not really clear, and based on the manual about the function I assume that the INF could be specific in case the room unit is configured as RGT2 only:

I'll try to detect the INF-messages of the room temperature coming from an QAA75 configured as RGT1 and RGT2 so that we can see if they're really different somehow..

[1coderookie]

Ok, now it's getting interesting and it seems like we have some kind of wrong coIDs working right now..

1) All telegrams from connected QAA75, controller: RVS63, room temp INFs are coming in every 1-2 minutes; other settings within the QAA75: nr42 - HK1 ; nr44 - together with HK1; nr46 - together with HK1; nr47 - for all dedicated heat circuits

First probable error: After I set room unit as RGT1, this telegram appeared:

11:08:46.198 -> RGT1->HEIZ SET  700 Heizkreis 1 - Betriebsart: 65535
11:08:46.231 -> DC 86 00 0D 03 3D 2D 05 74 01 01 A1 7A 
11:08:46.297 -> HEIZ->RGT1 ACK  700 Heizkreis 1 - Betriebsart: 
11:08:46.297 -> DC 80 06 0B 04 2D 3D 05 74 58 5F 

-> the "65535" was added recently to the "---" message - don't know why this one appeared here though, just wanted to tell you guys.. -> Judging on the telegrams that the QAA55 sends (see underneath), this "65535" isn't correct though, but compare by yourself..

QAA75 as RGT1: The only INF that comes in regularly every 1-2min from the RGT1 is this one:

11:19:07.855 -> RGT1->HEIZ INF 7165 Wartung/Sonderbetrieb - Wärmebnahmezwang TWW: CHOICE len !=2: 05 23 00 
11:19:07.888 -> DC 86 00 0E 02 3D 2D 02 15 05 23 00 41 AA 
-> room temperature at that time: 20.5°C

Up to me it's weird that this should be an INF coming from the room unit which is spreading the 7165 message - I'd expect that one coming from the controller itself, an not from a room unit?! So maybe this coID is the one for the room temp? Actually I think so, cuz that's the only INF coming in..

Checking 7165:

11:21:55.582 -> GET /7165 HTTP/1.1
11:21:56.145 -> /7165
11:21:56.311 -> LAN->HEIZ QUR 7165 Wartung/Sonderbetrieb - Wärmebnahmezwang TWW: 
11:21:56.311 -> DC C2 00 0B 06 2D 3D 02 15 21 9F 
11:21:56.311 -> HEIZ->LAN ERR 7165 Wartung/Sonderbetrieb - Wärmebnahmezwang TWW: error 7
11:21:56.311 -> DC 80 42 0C 08 3D 2D 02 15 07 BD 76 
11:21:56.311 -> #7165:  (parameter not supported)

And 7165 isn't available at all, not even from the OEM level, so I really think that this CoID is somehow buggy/wrong..

---

QAA75 as RGT2 room temp(?) INFs:

10:42:08.030 -> RGT2->HEIZ INF      3E2E0215 04 EC 00 
10:42:08.063 -> DC 87 00 0E 02 3E 2E 02 15 04 EC 00 BE DB
-> 19.7°C
--
10:54:08.906 -> RGT2->HEIZ INF      3E2E0215 05 04 00 
10:54:08.906 -> DC 87 00 0E 02 3E 2E 02 15 05 04 00 10 F0 
-> 20.1°C

---

QAA75 as RGT3/P: Seems to be addressed as CNTR btw:

11:05:53.865 -> CNTR->HEIZ QUR 8007 Status - Status Solar: 
11:05:53.865 -> DC 88 00 0B 06 3D 05 07 AE D8 D5 
11:05:53.965 -> HEIZ->CNTR ANS 8007 Status - Status Solar: 63 - Einstrahlung ungenügend
11:05:53.965 -> DC 80 08 0D 07 05 3D 07 AE 00 3F B7 F9 

No room temp as INF transmitted, probably due to the fact that 1350 isn't available (HK3/P is set to ON though) within that controller.. Which is kinda weird though, cuz the QAA55 is sending a regularly INF anyway - but I guess that's just because it's pretty dumb and just sends it anyway..?! See below..

---

2.) Now all telegrams coming from QAA55 as room unit, controller RVS63:

QAA55 as RGT1: After configuring as RGT1:

12:10:52.262 -> RGT1->HEIZ QUR 10102 Benutzerdefiniert - INFO HK1 - TBD: 
12:10:52.262 -> DC 86 00 0B 06 3D 2D 02 11 C0 62 
12:10:52.361 -> HEIZ->RGT1 ANS 10102 Benutzerdefiniert - INFO HK1 - TBD: 01 01 2A 84 FF FF FF FF 00 05 
12:10:52.394 -> DC 80 06 15 07 2D 3D 02 11 01 01 2A 84 FF FF FF FF 00 05 98 77 
12:10:52.593 -> HEIZ->RGT1 ANS 10100 Benutzerdefiniert - Systemstatus: 00000100
12:10:52.626 -> DC 80 06 0F 07 05 3D 02 13 04 00 40 CB 7E 97 

Assumingly the room temp INFs, same as above:

11:38:41.641 -> RGT1->HEIZ INF 7165 Wartung/Sonderbetrieb - Wärmebnahmezwang TWW: CHOICE len !=2: 04 E3 00 
11:38:41.641 -> DC 86 00 0E 02 3D 2D 02 15 04 E3 00 60 CE 
--
11:39:41.551 -> RGT1->HEIZ INF 7165 Wartung/Sonderbetrieb - Wärmebnahmezwang TWW: CHOICE len !=2: 04 E6 00 
11:39:41.551 -> DC 86 00 0E 02 3D 2D 02 15 04 E6 00 9F 3B 

-> ok, this really can't be 7165, cuz the QAA55 is pretty dumb! No other INF comes in, but the QAA55 only can send room temp by itself!

---

QAA55 as RGT2: Message after configuring as room unit 2:

11:41:01.028 -> RGT2->HEIZ QUR      2E3E0211 
11:41:01.061 -> DC 87 00 0B 06 3E 2E 02 11 45 3D 
11:41:01.161 -> HEIZ->RGT2 ANS      2E3E0211 01 01 24 84 8B 90 FF FF 00 05 
11:41:01.161 -> DC 80 07 15 07 2E 3E 02 11 01 01 24 84 8B 90 FF FF 00 05 6B 9A

-- Assumingly the room temp INFs:

11:42:03.528 -> RGT2->HEIZ INF      3E2E0215 04 EF 00 
11:42:03.528 -> DC 87 00 0E 02 3E 2E 02 15 04 EF 00 EB 88 
--
11:43:03.648 -> RGT2->HEIZ INF      3E2E0215 04 F2 00 
11:43:03.648 -> DC 87 00 0E 02 3E 2E 02 15 04 F2 00 9E A7 
-> 19.8°C

---

QAA55 as RGT3: After setting QAA55 to 'ru3' -> room unit 3, these telegrams appeared:

11:44:22.272 -> CNTR->HEIZ QUR      2F3F0211 
11:44:22.305 -> DC 88 00 0B 06 3F 2F 02 11 DD 7B 
11:44:22.404 -> HEIZ->CNTR ANS      2F3F0211 00 00 FF FF FF FF FF FF 00 00 
11:44:22.404 -> DC 80 08 15 07 2F 3F 02 11 00 00 FF FF FF FF FF FF 00 00 64 F9 
11:44:22.537 -> CNTR->HEIZ QUR      053F0213 
11:44:22.537 -> DC 88 00 0B 06 3F 05 02 13 BC 3E 
11:44:22.636 -> HEIZ->CNTR ANS      053F0213 04 00 40 CB 
11:44:22.636 -> DC 80 08 0F 07 05 3F 02 13 04 00 40 CB 4D 0E 

-- Assumingly the room temp INFs:

11:44:24.658 -> CNTR->HEIZ INF      3F2F0215 04 F5 00 
11:44:24.658 -> DC 88 00 0E 02 3F 2F 02 15 04 F5 00 71 C2 
--
11:45:24.541 -> CNTR->HEIZ INF      3F2F0215 04 FB 00 
11:45:24.541 -> DC 88 00 0E 02 3F 2F 02 15 04 FB 00 52 CD 
-> (_maybe_ 19.9°C)
--
11:46:24.494 -> CNTR->HEIZ INF      3F2F0215 04 FE 00 
11:46:24.494 -> DC 88 00 0E 02 3F 2F 02 15 04 FE 00 AD 38 
-> 20.0°C

I can check again all of the above with a RVS43 if you want..

[fredlcore]

First of all, please ignore the text after a SET telegram. I feel I say this once every couple of months, but it has to be ignored because the enable/disable byte is exactly the opposite of a QUR telegram, and I didn't want to bother with it for time and flash memory reasons. Because it thinks it is "disabled", it says 65535 or "---". 7165 is displayed because it has the command ID 3D2D0215 which matches the inverted two bytes of 2D3D0215. @dukess: I think this parameter was added by you - could you please check if that parameter also works with 3D3D0215? Because usually the second byte seems to be ignored anyway (except very few cases). That would avoid this confusion in the future.

As for the room temperature INF telegrams, these are the ones we already have in parameters 10000-10002. The interesting matter here is that bus ID 08 is also used by one of the Siemens devices (I think it was the ACS700), that's why it says CNTR here. The question remains whether it HAS to be sent from a specific room device, or whether sending it to the correct command ID would be enough. If you, @1coderookie, can see whether the room temperature is accepted for HC2, please try and send the room temperature from bus ID 06 (RGT1), 07 (RGT2) and from 66 (LAN) and let us know whether the temperature is received/accepted by the heater (parameter 8770). Then we know for sure whether it's necessary to send the room temperature from a given room device.

[1coderookie]

So it seems that I wasted my time and gave you guys useless informations - sorry for that.

First of all, please ignore the text after a SET telegram. I feel I say this once every couple of months, but it has to be ignored because the enable/disable byte is exactly the opposite of a QUR telegram, and I didn't want to bother with it for time and flash memory reasons. Because it thinks it is "disabled", it says 65535 or "---".

I know, but in this case I posted it on purpose, because a) that telegram appeared when I configured the QAA75 as RGT1 (within the QAA) and that SET-command didn't really made sense to me in that situation, especially because b) I didn't deactivate anything (what the 700-SET-telegram seems to say). The heater mode was 'reduced' mode in that time btw. Just for your information - I don't know if that maybe could have been useful somehow..

7165 is displayed because it has the command ID 3D2D0215 which matches the inverted two bytes of 2D3D0215.

Also that I understand - but because it seems to me that this INF message is the one from the RGT1 room temp, I wanted to tell you this.

(...) Then we know for sure whether it's necessary to send the room temperature from a given room device.

No, seems to reach HC2 anyway:

16:42:47.860 -> GET /I10001=19.5 HTTP/1.1
16:42:48.423 -> /I10001=19.5
16:42:48.423 -> set ProgNr 10001 = 19.5setting line: 10001 val: 04 E0 00 
16:42:48.556 -> LAN->HEIZ INF      3E2E0215 04 E0 00 
16:42:48.556 -> DC C2 00 0E 02 3E 2E 02 15 04 E0 00 36 6D 

16:42:57.482 -> GET /8770 HTTP/1.1
16:42:58.012 -> /8770
16:42:58.874 -> LAN->HEIZ QUR 8770 Diagnose Verbraucher - Raumtemperatur 2: 
16:42:58.874 -> DC C2 00 0B 06 3D 2E 05 1E 08 F7 
16:42:58.874 -> HEIZ->LAN ANS 8770 Diagnose Verbraucher - Raumtemperatur 2: 19.5 °C
16:42:58.874 -> DC 80 42 0E 07 2E 3D 05 1E 00 04 E0 51 69 
16:42:58.874 -> #8770: 19.5 °C

---

16:44:50.030 -> GET /I10001=19.5 HTTP/1.1
16:44:50.560 -> /I10001=19.5
16:44:50.593 -> set ProgNr 10001 = 19.5setting line: 10001 val: 04 E0 00 
16:44:50.693 -> RGT1->HEIZ INF      3E2E0215 04 E0 00 
16:44:50.693 -> DC 86 00 0E 02 3E 2E 02 15 04 E0 00 23 FF 

16:44:54.639 -> GET /8770 HTTP/1.1
16:44:55.170 -> /8770
16:44:55.369 -> RGT1->HEIZ QUR 8770 Diagnose Verbraucher - Raumtemperatur 2: 
16:44:55.402 -> DC 86 00 0B 06 3D 2E 05 1E F1 4A 
16:44:55.402 -> HEIZ->RGT1 ANS 8770 Diagnose Verbraucher - Raumtemperatur 2: 19.5 °C
16:44:55.402 -> DC 80 06 0E 07 2E 3D 05 1E 00 04 E0 8E 46 
16:44:55.402 -> #8770: 19.5 °C

---

16:46:07.546 -> GET /I10001=19.5 HTTP/1.1
16:46:08.076 -> /I10001=19.5
16:46:08.109 -> set ProgNr 10001 = 19.5setting line: 10001 val: 04 E0 00 
16:46:08.208 -> RGT2->HEIZ INF      3E2E0215 04 E0 00 
16:46:08.208 -> DC 87 00 0E 02 3E 2E 02 15 04 E0 00 FB B6 

16:46:11.789 -> GET /8770 HTTP/1.1
16:46:12.320 -> /8770
16:46:12.519 -> RGT2->HEIZ QUR 8770 Diagnose Verbraucher - Raumtemperatur 2: 
16:46:12.519 -> DC 87 00 0B 06 3D 2E 05 1E B6 99 
16:46:12.519 -> HEIZ->RGT2 ANS 8770 Diagnose Verbraucher - Raumtemperatur 2: 19.5 °C
16:46:12.552 -> DC 80 07 0E 07 2E 3D 05 1E 00 04 E0 E1 03 
16:46:12.552 -> #8770: 19.5 °C

[fredlcore]

No one's blaming you ;) - but thanks for testing the room temperature matter, because if I remember correctly, we told people (or people told us) that you have to register your device as RGT2 for some parameters to take effect on HC2. I think that was the room temperature, wasn't it? So in that case, there would not be any reason to use BSB-LAN as RGT1/2/3 anymore?

[1coderookie]

Well, look at the screenshot from the manual of the RGT I posted above: If you want to control an HC2 only, then one has to configure it as RGT2. If you configure it as RGT1, then you have to make settings how the other HCs should be controlled (together or separeted). In the past (when we had the adapter configured as RGT1 by default) we had some feedback that controlling a HC2 was only possible after configuring BSB-LAN as RGT2 and I think that was also belonging to the room temp. (Btw: I recently asked that guy again (not the first time though) if he please could check if everything would be possible now that we have the adapter configured as LAN with address 66, but -surprise surprise- no reaction..) Now it seems that transmitting a room temp to HC2 is also possible without configuring the adapter as a RGT2, correct. Guess it's because we (now/in the meantime) got the correct CoID for that, and because it's transmitted as an INF, the controller doesn't bother/ask where it comes from..

[fredlcore]

Yes, I was wondering what it means that one room controller can be applied to several HCs at the same time. Here it would be interesting to set RGT1 to be in charge for HC1 and HC2. From my understanding, it would have to send two INFs then, one with 3D2D0215 and one with 3E2E0215 (in the notation as it appears in the telegram, the actual command IDs would be 2D3D0215 and 2E3E0215 respectively). Just in case you have time to check this, that would be an interesting piece of information because we would know if we can ignore this setting completely (because we already decide the "destination" by using different parameters) or whether it still changes something we don't know about yet.

[dukess]

Wow guys you are incredible!

[dukess]

If one device can be as RGT for different HC then i have new function. In _config.h user should to add

+#define RGT_EMULATOR
int rgte_sensorid[3] = {0, 0, 0}; //Temperature sensor program ID for RTG1 - RTG3. If zero then RTG will not be emulated.

and set here or in webconfig program numbers which referenced to sensor temperature (Dallas, DHT22, MAX! or other perspective devices). After that BSB-LAN will send INF every minute. If program number will be 0 then INF will not send. https://github.com/dukess/bsb_lan/commit/208894c1009cd5c0db741c1d662da73f68e7f40e

Note: it not tested yet.

[1coderookie]

Yes, I was wondering what it means that one room controller can be applied to several HCs at the same time. Here it would be interesting to set RGT1 to be in charge for HC1 and HC2. From my understanding, it would have to send two INFs then, one with 3D2D0215 and one with 3E2E0215 (in the notation as it appears in the telegram, the actual command IDs would be 2D3D0215 and 2E3E0215 respectively). Just in case you have time to check this, that would be an interesting piece of information because we would know if we can ignore this setting completely (because we already decide the "destination" by using different parameters) or whether it still changes something we don't know about yet.

So, I changed the setting of no42 which is "assignment device room unit 1" from HC1 to "all HC" (so not only HC1&2):

09:02:55.733 -> RGT1->HEIZ SET  700 Heizkreis 1 - Betriebsart: 65535
09:02:55.767 -> DC 86 00 0D 03 3D 2D 05 74 01 01 A1 7A 
09:02:55.833 -> HEIZ->RGT1 ACK  700 Heizkreis 1 - Betriebsart: 
09:02:55.833 -> DC 80 06 0B 04 2D 3D 05 74 58 5F 
09:02:55.933 -> RGT1->HEIZ SET      2E3E0574 01 01 
09:02:55.933 -> DC 86 00 0D 03 3E 2E 05 74 01 01 81 48 
09:02:56.032 -> HEIZ->RGT1 ACK      2E3E0574 
09:02:56.032 -> DC 80 06 0B 04 2E 3E 05 74 9A D3 

Please keep in mind that also in my previous tests no room temp was sent from the QAA75 for HC3 (but was sent from the QAA55) - so that's why also now it won't appear!
Also I made sure that parameter 47 ("room temperature unit 1" - options: 'for HC1' / 'for all assigned HCs') still was set to 'for all assigned HCs' like yesterady already - otherwise it wouldn't work.

09:03:58.522 -> RGT1->HEIZ INF 7165 Wartung/Sonderbetrieb - Wärmebnahmezwang TWW: CHOICE len !=2: 04 89 00 
09:03:58.555 -> DC 86 00 0E 02 3D 2D 02 15 04 89 00 84 2F 
09:03:58.820 -> RGT1->HEIZ INF      3E2E0215 04 89 00 
09:03:58.820 -> DC 86 00 0E 02 3E 2E 02 15 04 89 00 92 4D 

Here we can see clearly that the QAA75 sends the room temp as specific INFs to all HCs.

---

And the same goes for no48 ("presence button unit 1" - options: none/for HC1/for all assigned HCs): If I set it to "for all assigned HCs" then it sends the specific SET command to all HCs:

• switching to reduced mode:

  09:19:33.281 -> RGT1->HEIZ SET  701 Heizkreis 1 - Präsenztaste (temporäre Abwesenheit): 65535
  09:19:33.281 -> DC 86 00 0D 03 3D 2D 05 72 01 01 13 DA 
  09:19:33.348 -> HEIZ->RGT1 ACK  701 Heizkreis 1 - Präsenztaste (temporäre Abwesenheit): 
  09:19:33.381 -> DC 80 06 0B 04 2D 3D 05 72 38 99 
  09:19:33.447 -> RGT1->HEIZ SET 1001 Heizkreis 2 - Präsenztaste (temporäre Abwesenheit): ---
  09:19:33.447 -> DC 86 00 0D 03 3E 2E 05 72 01 01 33 E8 
  09:19:33.547 -> HEIZ->RGT1 ACK 1001 Heizkreis 2 - Präsenztaste (temporäre Abwesenheit): 
  09:19:33.547 -> DC 80 06 0B 04 2E 3E 05 72 FA 15 

• switching to comfort mode:

  09:20:27.250 -> RGT1->HEIZ SET  701 Heizkreis 1 - Präsenztaste (temporäre Abwesenheit): 65535
  09:20:27.283 -> DC 86 00 0D 03 3D 2D 05 72 01 00 03 FB 
  09:20:28.377 -> HEIZ->RGT1 ACK  701 Heizkreis 1 - Präsenztaste (temporäre Abwesenheit): 
  09:20:28.377 -> DC 80 06 0B 04 2D 3D 05 72 38 99 
  09:20:28.576 -> RGT1->HEIZ SET 1001 Heizkreis 2 - Präsenztaste (temporäre Abwesenheit): ---
  09:20:28.576 -> DC 86 00 0D 03 3E 2E 05 72 01 00 23 C9 
  09:20:28.675 -> HEIZ->RGT1 ACK 1001 Heizkreis 2 - Präsenztaste (temporäre Abwesenheit): 
  09:20:28.675 -> DC 80 06 0B 04 2E 3E 05 72 FA 15 

[1coderookie]

If one device can be as RGT for different HC then i have new function. In _config.h user should to add

+#define RGT_EMULATOR
int rgte_sensorid[3] = {0, 0, 0}; //Temperature sensor program ID for RTG1 - RTG3. If zero then RTG will not be emulated.

and set here or in webconfig program numbers which referenced to sensor temperature (Dallas, DHT22, MAX! or other perspective devices). After that BSB-LAN will send INF every minute. If program number will be 0 then INF will not send. dukess@208894c

Note: it not tested yet.

That's pretty cool! Maybe it would be useful if you could add a function like that for the presence button also? So that one just has to set one certain (special) parameter number and then BSB-LAN will send the SET commands to all HCs like the room unit does? Could be useful maybe for someone who has more than one HC..?

[fredlcore]

Thanks for the comprehensive testing, @1coderookie! Two things are interesting here: When you change parameter 42, it sets parameter 700 and 1000 to "automatic" - it doesn't do anything else (unless there are telegrams that you didn't include). That is quite strange. Or maybe not, if it is really designed in such a way that the room unit decides on its own which kind of room temperature telegrams to send, which or other logs clearly show. So I think it's now safe to say that no scenario exists where BSB-LAN should run as RGT1, correct? Then we should maybe remove the references to that in the config file because it could still make people try it out which then might result in an address conflict if a QAA exists.

[fredlcore]

@dukess: Your idea sounds great, I just would try to prevent working with defines in the config if possible and make this configurable via the webinterface. One other idea I had in that regard was to poll Shellys (https://shelly.cloud/). They are getting more and more popular and can easily be installed without any cables etc.

If we go that way, we should provide up to five sensors for each HC and if more than one sensor is entered, an average should be calculated of the (up to five) sensors. Because that would really be a big advantage compared to current room units. If that one room is getting warmer than the others (because of large windows and direct sun), then it will have an impact on all other rooms.

And one more thing, @dukess: Could you please check if parameter 7165 also works with 3D3D0215 instead 3D2D0215?

[1coderookie]

Yes, I really don't understand why the SET commands are sent when I change the setting of no42 either, cuz that really changes the settings! I just did another test: I set the mode to 'comfort' (the 'real' comfort, not within the automatic mode!) and then I changed the setting of no42 - wow, doing that really changes the heating mode to 'automatic'! Strange..

Yes, I'd also say that we should remove the comment in the config.h for RGT1 completely. If one still wants to change the setting/address for whatever reasons, then he'll find the specific addresses for RGT1&2 within the manual in the address table anyway..

[1coderookie]

@dukess: When you are checking and probably changing that for 7165, could you please add an "a" to the Name? There is one missing: "Wärmebnahmezwang" should be "Wärmeabnahmezwang" - thanks ;)

[fredlcore]

That's in the LANG_DE.h, I can take care of that...

[dukess]

we should provide up to five sensors for each HC and if more than one sensor is entered, an average should be calculated of the (up to five) sensors.

I think my code may be adopt without big efforts, so yes.

Could you please check if parameter 7165 also works with 3D3D0215 instead 3D2D0215?

I tried to not forget about it because next time will be at weekend.

Maybe it would be useful if you could add a function like that for the presence button also?

I think it possible: https://github.com/dukess/bsb_lan/commit/c192995bba7419f4ef735d390bd7477ffff76fd3

[dukess]

Ouch. I forgot about impossibility to query 701 program. We should send "---" to 701 (1001, 1301) for mode switch?

[fredlcore]

Yes, we cannot query 701 etc. What do you mean "send '---' to 701 for mode switch"?

[dukess]

What do you mean "send '---' to 701 for mode switch"?

09:19:33.281 -> RGT1->HEIZ SET 701 Heizkreis 1 - Präsenztaste (temporäre Abwesenheit): 65535 09:19:33.281 -> DC 86 00 0D 03 3D 2D 05 72 01 01 13 DA 09:19:33.348 -> HEIZ->RGT1 ACK 701 Heizkreis 1 - Präsenztaste (temporäre Abwesenheit): 09:19:33.381 -> DC 80 06 0B 04 2D 3D 05 72 38 99

Looks like I got it wrong.

If I correctly understood from the discussion the principle of operation of the presence button, then the first press turns on the comfort mode, and the second - the economy mode? The boiler itself "understands" which mode it should switch to, or do we set this mode for it (values "1" and "2" from ENUM701)?

[fredlcore]

No, there are dedicated values for comfort and reduced mode (see ENUM701). The only problem is that you cannot read this parameter to detect which mode is currently active. You have to resort to the 8000++ parameters for that.

[dukess]

In this case i can propose that:

1. first pressing after booting always will set "Comfort" mode.
2. After that flag will be stored in variable.
3. When button will be pressed again will be set "Reduced" mode.
4. Flag will be cleared.
5. Repeating steps 1-4.

[1coderookie]

Ah, now I think I get what you mean, you're talking about the implementation of the button, right? At the original room units there is also just one button and the belonging CoID is sent automatically, depending on wheter the reduced or the comfort mode is active (works only in automatic mode though!). Within the display of the room unit there is the belonging symbol (moon=reduced, sun=comfort), so I guess the QAA 'knows' (I guess by the BCs) which mode is active and just sends the belonging CoID to switch into the other mode. If you solve the problem like you suggested and don't have a display connected to the setup, you'd have to check everytime via webinterface if the button-push triggered the correct mode. Kinda uncomfortable in my opinion. Maybe you could solve it that way, that by pushing the button the program first checks which mode is active and then it sends the belonging CoID to switch to the other mode (don't know which program number tells us about the comfort/reduced mode in heater mode 'automatic' right now though or if it's even possible at all..)?

[fredlcore]

But why do we need a toggle if we have the option of sending the dedicated state? Or do you mean a hardware button? In that case I would add a LED that indicates the current mode so you have an immediate visible feedback which mode is active now.

[1coderookie]

Judging on the comment "Add handling presence buttons and TWW push on pins D21 (INT 2)(TWW push), D20 (INT 3)(presence ROOM1), D19 (INT 4)(presence ROOM2), D18 (INT 5)(presence ROOM3)" to his solution (see the link a few comments above) I think so, yes..

[fredlcore]

That's not in this issue, where do you see this?

[fredlcore]

From this reference here: http://www.robgray.com/temp/Due-pinout-WEB.png D18 to D21 are special use pins such as Serial1 TX/RX SDA/SCL etc. It would probably be best to use odd-numbered pins from 27 to 47 for that because they are available through the BSB-LAN board.

[dukess]

At the original room units there is also just one button and...

Thank you for details, need to think it!

Or do you mean a hardware button?

Yep. I made code that handle interrupts (and 4 buttons, one for TWW - here is all clear and simple, and 3 for RGT). About pins: D2, D3 and D18 to D21 is available for interrupts in Mega (First i saw info for Mega so i assumed that Due using same pins). As i saw later Due can do interrupds on any D pins.

By the way i catch trouble with erasing-EEPROM-at-start function on Mega: until used pin was 51 EEPROM was erased on every startup. After changing to pin 47 uncontrollable erasing was stopped. So need more testing on different devices.

[1coderookie]

That's not in this issue, where do you see this?

It is, he posted it a few entries above (6hrs before):

I think it possible: dukess@c192995

FYI about that pinout you mentioned:

From this reference here: http://www.robgray.com/temp/Due-pinout-WEB.png

That's the one I recently added in appendix B ;)

[dukess]

Maybe you could solve it that way, that by pushing the button the program first checks which mode is active and then it sends the belonging CoID to switch to the other mode (don't know which program number tells us about the comfort/reduced mode in heater mode 'automatic' right now though or if it's even possible at all..)?

Tried your way: https://github.com/dukess/bsb_lan/commit/c251e1d1ca39d76f4d6d097062bc00c9a241e1ee

[1coderookie]

Cool :) Made some comments within that, hope I did it right.. ;)

[fredlcore]

That's the one I recently added in appendix B ;)

I know, but I thought I link to the original ;)

[dukess]

@fredlcore @1coderookie Thank you for your work! New commit with changes: https://github.com/dukess/bsb_lan/commit/c4c427c0738438580f0d74c310a2d6d1aa1c5be3 Pins can be adjustable. Now using comparsion between current and comfort setpoints for detection current state. (And heater should be in "Automatic" mode, sure!). Web configuration updated.

[fredlcore]

@dukess: We found out yesterday that we can use parameter 10102 to detect what kind of automatic mode is in use: The second byte from the left indicates the automatic state: 0x01 = Automatic in reduced mode 0x02 = Automatic in comfort mode 0x03 = Automatic in comfort mode, but pushed into reduced mode through presence button 0x04 = Automatic in reduced mode, but pushed into comfort mode through presence button

So 0x01 and 0x04 mean the heater is in reduced mode and 0x02 and 0x03 mean that the heater is in comfort mode. But note that this only applies if the general mode is automatic, so you have to check 700 first.

The same goes for other HCs, so 10202 and 10203 can be used accordingly.

[dukess]

Wow, cool!

[1coderookie]

Great! But I'm afraid I have to tell you that you'd have to rewrite your code again, cuz last night we found out how the state can be queried by one specific parameter for each HC. But Frederik will tell you, he discovered how the bytes of that telegram are assigned to the different states. (Oh, I just see that he was faster ;) ) Btw: Should also be possible for 10104 = HC3, but that one doesn't work for me anyway.. 10102 = HC1, 10103 = HC2

Something in general about your solution (I'm making the comments here, so that we have everything in one place/discussion): You wrote "// Pins on Mega can be (Digital) 2, 3, 18, 19, 20, 21 // On Due any Digital pins can be selected excluding 18, 19."

• Please add 13 to that at Due, cuz it's the pin which maybe would be used within the WiFi solution (SS). Also that one is pretty free to choose, it's the default pin in the config.h.
• We also have some other pins used in the default config.h, like 7 for OneWire, 2&3 for DHT etc. Also many pins which are already used (like for the LAN shield etc) and which are reserved. => So maybe it would be better if you write something like "Any digital pins could be used, but make sure that they aren't in use already (e.g. sensors) or within the list of the protected pins!". As a default value we could think about some certain pins we already put in there as default values, I guess that's easier for some people then not naming any specific number.

Then I have some questions, I'm not sure if I got it right the other day:

• So, we can add a presence button for each HC now. Means, one has the possibility to control each HC on it's own. But: Did you also implement the function that it would be possible to control all HC with one button?
• I think you made it possible, that up to 5(?) sensors could be used for the room temp measurement for each HC. For OneWire we have the specific sensor ID (and all sensors could even be connected at the same pin), but DHT22 doesn't have these IDs, they need one pin for each sensor. BME280 (if coming) also don't have specific IDs, only two possible I2C addresses. How does one have to make the entries within the config.h for either the OneWire-sensorIDs and/or the DHT22-pins (or BME280 probably in the future)? And: Is it possible to also send/use that room temp to/for all HCs and not only for one specific HC?

[fredlcore]

I just realized that pin 13 is also the pin for the builtin LED (on both the Due and the Mega. So @1coderookie, we have to change the default SS pin for the WiFi module to 12 then. Otherwise the LED would constantly be blinking. So for the pins not to be used, number 12 and 13 should be added.

[fredlcore]

BTW: I think the easiest way is to query parameter 1020x and then access the second byte directly via (the global) msg[1] byte.

[1coderookie]

So 0x01 and 0x04 mean the heater is in reduced mode and 0x02 and 0x03 mean that the heater is in comfort mode.

Wait, are you sure you didn't mix up 0x03 & 0x04?!? Just checked the telegrams from last night. 0x03 is reduced coming from comfort by presence button; 0x04 is comfort coming from reduced by presence button. Just to give you an example: 10102 Benutzerdefiniert - INFO HK1 - TBD: 01022A84FFFFFFFF0001 - unknown type 10103 Benutzerdefiniert - INFO HK2 - TBD: 010224848B90FFFF0001 - unknown type -> HC1 & HC2 were in automatic/comfort at that time -> pushed presence button to switch to reduced: 10102 Benutzerdefiniert - INFO HK1 - TBD: 01032A84FFFFFFFF0001 - unknown type 10103 Benutzerdefiniert - INFO HK2 - TBD: 010324848B90FFFF0001 - unknown type -> HC1 & HC2 are in automatic/reduced

Here are the telegrams from last night:

Schutzbetrieb:
10102 Benutzerdefiniert - INFO HK1 - TBD: 00002A8DFFFFFFFF0005 - unknown
type

Automatik/Komfort (laut Zeitprogramm):
10102 Benutzerdefiniert - INFO HK1 - TBD: 01022A8DFFFFFFFF0001 - unknown type
-> Umschaltung mit /S701=1 (**-> reduced**):
10102 Benutzerdefiniert - INFO HK1 - TBD: 01**03**2A8DFFFFFFFF0001 - unknown type

Automatik/Reduziert (laut Zeitprogramm):
10102 Benutzerdefiniert - INFO HK1 - TBD: 01012A8DFFFFFFFF0001 - unknown type
-> Umschaltung mit /S701=2 (**-> comfort**):
10102 Benutzerdefiniert - INFO HK1 - TBD: 01**04**2A8DFFFFFFFF0001 - unknown type

Dauernd Reduziert:
10102 Benutzerdefiniert - INFO HK1 - TBD: 02012A8DFFFFFFFF0001 - unknown type

Dauernd Komfort:
10102 Benutzerdefiniert - INFO HK1 - TBD: 03022A8DFFFFFFFF0001 - unknown type