1coderookie
commented
3 years ago And here a little screenshot of that QAA-line:
Closed 1coderookie closed 3 years ago
1coderookie
commented
3 years ago And here a little screenshot of that QAA-line:
1coderookie
commented
3 years ago Now in your EEPROM stored QAA50: 52 00 00 00 00 42 42
Just in case that it could be a helpful information: I never set the QAA50, I dind't change anything within the config.h, always used the default settings (which ist QAA70: byte QAA_TYPE = 0x53; // 0x53 = QAA70, 0x52 = QAA50)
fredlcore
commented
3 years ago You set it the moment you save the configuration. Then all the config options are written to EEPROM exactly as they are displayed in the config page. So even if you just set Read config from EEPROM to yes, the QAA50 value gets written. That's why you have to erase the EEPROM first.
dukess
commented
3 years ago Ok. I will try tomorrow (or may be today) erase eeprom and look on this one more time. BTW: we not need QAA_TYPE as variable, we can use it as definition (#define QAA_TYPE 0x52/0x53) for memory saving. I did it as variable on early stage but never use it as variable.
1coderookie
commented
3 years ago @fredlcore: Sorry, but I don't get it - I flashed the default config.h where the QAA70 is preset by default. To a brand new EEPROM. I also did /NE to erase the EEPROM. I never set the QAA50 anywhere - neither in the config.h nor via webinterface. I just didn't touch it. Still the QAA50 shows up. EDIT: So I just wonder where it comes from, because the default setting is QAA70 and I never ever changed anything anywhere..
What you said would only make sense to me, if the QAA50 would be set by default if PPS wasn't used and therefore the default value of the config.h would be ignored. If it's like that - it's fine with me. I just tested it with the default config.h, expected the same output within the webinterface as the config.h-values are and saw, that it's not the same. I think/thought that it's a bug and reported it here.
fredlcore
commented
3 years ago I'm only saying that the moment you change anything in the webinterface all options are written. So if at any point you were writing the config (as you did in some of your testing), the "wrong" QAA50 value was written to EEPROM, too. In the meantime there have been a few bugfixes that should prevent that behaviour, but nevertheless your logs indicate that the QAA50 value is in the EEPROM and will stay there until erased.
fredlcore
commented
3 years ago EDIT: I see that the 0x52 is still in the EEPROM dump after you issued /NE, so that's likely a problem. I don't exactly understand how the EEPROM is re-initialized after /NE because the "magic bytes" in the beginning are apparently written there, too, but the 0x52 should not be there if the value is initialized otherwise in _config.h.
1coderookie
commented
3 years ago So if at any point you were writing the config (as you did in some of your testing), the "wrong" QAA50 value was written to EEPROM, too. In the meantime there have been a few bugfixes that should prevent that behaviour,
Understood that - that's why I did the tests today with the latest version (after you merged the last pullrequest this morning, I think it was #201). So I expected this to be fixed. Because it wasn't and even showed up after /NE, I reported it again ;)
fredlcore
commented
3 years ago Correct :) - see my EDIT above.
1coderookie
commented
3 years ago Yep, just wanted to mention that I used the latest version which already included the latest QAA-bugfixes from this morning ;)
dukess
commented
3 years ago Just FYI:
Note: program was runned on Mega. QAA_TYPE = 0x53 After /NE: 96 03 31 7c 1d a2 4b 45 51 30 35 30 32 33 32 36 00 4b 45 51 30 35 30 35 30 38 30 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 00 42 42 00 00 03 00 01 fc 21 86 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Here we see PPS settings "without" values. But here must be one byte with 53 value. But in web config QAA type displayed correct
After /CI:
96 03 31 7c 1d a2 4b 45 51 30 35 30 32 33 32 36 00 4b 45 51 30 35 30 35 30 38 30 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 53 00 00 00 00 42 42 00 00 03 00 01 fc 21 86 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
All ok.
Switch to type 0x52 and /CI 96 03 31 7c 1d a2 4b 45 51 30 35 30 32 33 32 36 00 4b 45 51 30 35 30 35 30 38 30 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 52 00 00 00 00 42 42 00 00 03 00 01 fc 21 86 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Ok.
Change to type QAA_TYPE = 0x52 in config.h After /NE:
96 03 31 7c 1d a2 4b 45 51 30 35 30 32 33 32 36 00 4b 45 51 30 35 30 35 30 38 30 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 00 42 42 00 00 03 00 01 fc 21 86 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Same thing as above. But in web config QAA type displayed correct After /CI:
96 03 31 7c 1d a2 4b 45 51 30 35 30 32 33 32 36 00 4b 45 51 30 35 30 35 30 38 30 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 52 00 00 00 00 42 42 00 00 03 00 01 fc 21 86 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Switch to type 0x53 and /CI 96 03 31 7c 1d a2 4b 45 51 30 35 30 32 33 32 36 00 4b 45 51 30 35 30 35 30 38 30 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 53 00 00 00 00 42 42 00 00 03 00 01 fc 21 86 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
All ok. After reboot QAA type ok.
BUT: this code never(?) work: no debug messages, no EEPROM updates.
for (int i=PPS_TWS;i<=PPS_BRS;i++) {
if(pps_values[i] == (int16_t)0xFFFF) pps_values[i] = 0;
if (pps_values[i] > 0 && pps_values[i]< (int16_t)0xFFFF && i != PPS_RTI) {
printFmtToDebug(PSTR("Slot %d, value: %u\r\n"), i, pps_values[i]);
}
}
if(pps_values[PPS_QTP] == 0 || UseEEPROM != 0x96) {
pps_values[PPS_QTP] = QAA_TYPE;
writeToEEPROM(CF_ROOM_DEVICE);
}mystic.
dukess
commented
3 years ago Update: i checked it and code above working. Really QAA_type was writing in EEPROM in two different places. It not critical but not fine.And i have no idea how to defeat it. :-)
1coderookie
commented
3 years ago At least it's reassuring for me to know, that my description now somehow makes sense and that there really is a reason for that QAA-behaviour somewhere ;) But seriously: at least it's good that it's nothing critical (if this weird 'writing in EEPROM in two different places'-behaviour really only affects the QAA-type!?). Would the problem disappear somehow, if we would take the QAA-model out of the webinterface? So that one only has the ability to set the type within the config.h?
Btw @fredlcore: The QAA70 offers more functionality than the QAA50. So I was wondering why BSB-LAN offers also the function to imitate the QAA50 and if it wouldn't be sufficient to only set the QAA70 as the fixed type of room unit to be imitated by BSB-LAN. Possible benefit: In that case we could maybe completely get rid of the QAA50 and the error..?
When it comes down to the differences of the functionality between these two room units: did you ever try if the controller would take a command from BSB-LAN imitating a QAA50 which an original QAA50 doesn't even offer?
Here's a screenshot from a manual about the differences:
1coderookie
commented
3 years ago @dukess: Btw, did I get you right that you were using the webconfig with a Mega? So it is possible (somehow) to use webconfig on the Mega? Because this question came up in the forum and I didn't do any tests yet with v2.x and the Mega..
So I will proceed testing with Due and the recent version, but maybe not today and at this weekend, time is a bit short right now for me in these days..
fredlcore
commented
3 years ago @1coderookie: I only have a QAA70 and therefore can't really test the difference or whether some telegrams are different. Therefore I left the option for QAA50 in there. We could probably get rid of QAA50 eventually, but it would still be better to fix the error anyways...
dukess
commented
3 years ago But seriously: at least it's good that it's nothing critical (if this weird 'writing in EEPROM in two different places'-behaviour really only affects the QAA-type!?).
QAA_type saved twice in EEPROM: first time as "standalone" variable (pps_values[PPS_QTP]) and second time as part of pps_values array. In theory we can change one value in EEPROM cell for making different values but after /CI they will be synchronized. I can add conditions for physical excluding of "standalone" variable reading and writing to EEPROM but here no big reason do it now.
Would the problem disappear somehow, if we would take the QAA-model out of the webinterface? So that one only has the ability to set the type within the config.h?
This contradicts the idea of moving the configuration setting to web interface. :)
Btw, did I get you right that you were using the webconfig with a Mega?
@1coderookie Yep. In program was used external interface (with LANG C) and compiled these modules: WEBSERVER, IPWE, Verbose DEBUG, LOGGER, MAX_CUL, CONFIG_IN_EEPROM, WEBCONFIG. So program size was 237663 bytes. MQTT support "eat" 4,6 Kb, ONE_WIRE_BUS - 3,2Kb, DHT_BUS - 2,8 Kb, AVERAGES - 2,9 Kb. I.e. this solution will suit not for all users.
@fredlcore BTW: what you think about removing /T (Update: /B and /A too) command (because all sensors can be accesses through programs 20000-20700)?
fredlcore
commented
3 years ago Just for my understanding: Where does the value in pps_values array come from? Shouldn't it be erased after flash and then set to QAA_TYPE?
As for removing /T, /B and /A, I think we can remove them. If not now (where everybody is changing their configuration anyways), when then ;)?
malansk
commented
3 years ago I you remove the /T URL command, how can I read the sensor values from from WebGui ? I only have PPS, so I'm not shure how I can access the programs 20000-20700 ?
Same problem would happen with removal of /B (although with my PPS system I dont't get Brennerstatus anyway, but some other PPS system maybe do).
dukess
commented
3 years ago Where does the value in pps_values array come from? Shouldn't it be erased after flash and then set to QAA_TYPE?
Initially It come from _config.h. pps_settings will be erased only with /NE.
As for removing /T, /B and /A, I think we can remove them.
Roger.
malansk
commented
3 years ago @dukess In V2.0.14, ff I try to read One Wire Sensor with http://192.168.178.88/P20301 I only get Error Message "Bus-System: PPS Nur Lesen".
So If you really want to remove /T please make the One Wire Sensors accessible even if Bus system is set to PPS (not BSB/LPB).
1coderookie
commented
3 years ago As for removing /T, /B and /A, I think we can remove them. If not now (where everybody is changing their configuration anyways), when then ;)?
Why should we remove them? Does it take so much memory? Sure we can access them through parameter numbers (we already could before v2.x though), but if I rember correctly, one has to query not only one parameter now for e.g. getting the sensor-id and the value for a 1wire sensor at the same time. When querying /T, we get all sensors with the ids and the values at one time. In my opinion there are minimum two advantages of the /T etc functions: 1) It's easy when it comes down to the first usage or the replacement of a sensor, because one can see all ids&sensors and the changing value to identify a specific sensor just by using url/T. 2) Some of the code examples for other home automation systems in the manual use /T (or /B or /A in other examples) to query all sensors and then read out the ids&values they need from that output. If we delete /T and so on, these examples will become completely disfunctional. Also existing solutions of users, who already use these functions based on these examples and who just want to update to v2.x will encounter problems that they may not solve by themselve, because they are just not capable of adjusting the code..
So, I would say: please let these functions as they are..
1coderookie
commented
3 years ago ..and btw: I think also some of the modules for other home automation systems then FHEM which were developed by users also need these functions. If we delete them now, these modules will also encouter problems or will not longer work as expected..
malansk
commented
3 years ago Yes, that is also my usecase. Since my heating system has no Rücklauftemperatursensor, I use three One-Wire sensors (Rückauftemperatur nach Mischer, Rücklauftemperatur vor Mischer, Heizkellertemperatur) connected to BSB-Lan.
I use Homematic smarthome system with CuxD example script from the manual to read the values of these sensors with URL command /T. Then I have alle the relevant values in the Homematic system and can store them in common database for analysis with CCU Historian Datalogger.
Please let the /T function as it is.
dukess
commented
3 years ago Same problem would happen with removal of /B (although with my PPS system I dont't get Brennerstatus anyway, but some other PPS system maybe do
@malansk This is an important thing, thank you for reminding. Need to unlock K49 for PPS.
fredlcore
commented
3 years ago I think it's of course necessary to unlock K49 for PPS, but all other arguments can be easily resolved, because you can query all your sensors still in one page if you call for example http://x.x.x.x/20000-20999 I'm not even sure that it will break any existing external module structurally because all users have to do is change the parameters they are calling. All modules can already query "normal" parameters, so the sensors just fit in nicely. We won't even need any special examples anymore. It will save space in both BSB-LAN as well as the external modules (if they want to remove the then unnecessary code) and therefore these legacy URL calls should go.
dukess
commented
3 years ago Does it take so much memory? @1coderookie ~2 Kb.
I can offer other decision: we can wrap /T /B /A code in
...
and end user can do their choice.
fredlcore
commented
3 years ago That would still leave unnecessary code in the source. I really would like to take this 2.0 version to get rid of all the stuff that we have dragged on for years and which have been at times ugly workarounds. You have done a great job cleaning up a lot of this stuff. If we drag this on now, we will at least have it until version 3.0 for no good reason.
malansk
commented
3 years ago So in my current polling script:
================================== **
! BSB-Adapter Wert abfragen by Bratmaxe ! 29.10.2018 - V0.1 - Erste Version ! 11.11.2019 - V0.2 - Auslesen von Temperatursensoren hinzugefügt ! 15.11.2019 - V0.3 - Änderung der Ausleseart der Temperatursensoren mithilfe der ID
string CuxGeraetAbfrage = "CUX2801001:13"; ! GeräteAdresse des CuxD Execute Gerätes, welches die Abfragen ausführt string CuxGeraetLogging = ""; ! GeräteAdresse des CuxD Execute Gerätes, welches das Logging ausführt, Leer ("") lassen, wenn kein Cuxd-Highcharts Logging gewünscht string IPAdresseBSB = "192.168.178.88"; !IP_Adresse des BSB-Adapters string Wort = "T"; !Parameternummer: Beispiel Außentemperatur = 8700, Betriebsmodus = 700, eigene Temperatursensoren = T string TemperatursensorID = "287a77a730190184"; !Wenn Wort = "T", dann hier die ID des auszulesenden Temperatursensors eingeben, wird sonst ignoriert! string Variablename = "Rücklauf_vor_Kessel_Heizung"; ! Name der Systemvariable boolean Durchschnitt24h = false; ! true = Durchschnittswert holen, false = aktuellen Wert holen - diese muss vorher in der BSB_lan_config.h konfiguriert wurden sein!!! (Bei Wort = T wird dieser Parameter ignoriert)
I only would need to change: string Wort = "20301"; instead of: string Wort = "T";
I think I could do that :-)
However I don't know if the 1:1 relation would be ensured, now the script look explicitly for the ID of the propper sensor. With the 2031 parameter , I'm not shure if the sensor order would stay the same e.g. after reboot or after adding / removing sensors from the system (as mentioned on page 109 of the BSB-Lan manual).
For my system probably no issue, but there might be other usecases where users use a more dynamic configuration in regard of how many sensor are attached.
dukess
commented
3 years ago Enabling category 49 (User sensors) for PPS https://github.com/fredlcore/bsb_lan/pull/203
malansk
commented
3 years ago Thank you :-)
fredlcore
commented
3 years ago Yes, I think that should do it - as for the sorting of the sensors, I think it would be worth trying it out. We call the function in the 1Wire library which returns all the sensors in an array, but I'm not sure if the array is always sorted in the same way. If not, we could add code that it would do so, so that should not be a stumbling block. In any case it should of course be ensured that each sensor stays in its position - at least until new sensors are being added (in case we sort alphabetically or so).
fredlcore
commented
3 years ago Pull Request is merged now, so maybe you can check it out, @malansk, if it works with parameter numbers instead of /T?
1coderookie
commented
3 years ago That would still leave unnecessary code in the source.
If you guys want to delete that function, it's fine with me, but I'm not able to adjust the code examples for the different systems - just for your information. If you (fredlcore) announce this changement in the FHEM forum, hopefully the guys who wrote the examples/modules will read it and take care of that.. ;)
But looking on what you said about the memory and the unneccessary code, I have to pull up again the case with the possibility to choose between the QAA70&QAA50. Maybe you didn't get what I meant, because you wrote:
@1coderookie: I only have a QAA70 and therefore can't really test the difference or whether some telegrams are different. Therefore I left the option for QAA50 in there.
I wasn't talking about differences in the telegrams, because the QAA50 doesn't offer any option which the QAA70 doesn't have, see the screenshot above. If one wants BSB-LAN to imitate the room unit to control as much as possible, he would never choose the QAA50, because that one is just 'dumb' compared to the bigger QAA70. So up to me it doesn't really makes sense to even offer this possibility to choose between a 'dumb' room unit and one which offers much more options to control something or to set/change any settings within the controller. One would always choose the type which offers the most functionality. And if the end user is insecure and doesn't really know about these differences, he wouldn't touch this option anyway I guess (also because just by the name the QAA70 seems to be 'bigger' ;) .. Taking that option of the QAA50 away would also make the code smaller, would save space etc.pp. and could even be a solution to get rid of the problem that the QAA50 is set/displayed while the QAA70 should be.
1coderookie
commented
3 years ago In any case it should of course be ensured that each sensor stays in its position - at least until new sensors are being added (in case we sort alphabetically or so).
Iirc, the sensors are listed by the alphabetical&numerical order of the specific sensorID. That's why I asked you to add the function of displaying the ID within /T in the past, because without it the sensors just changed the order if any replacement/addition took place and one probably didn't realize right away that the order changed.
malansk
commented
3 years ago I have changed the one line in Bratmaxes script to use P20305 instead of the "T" & ID logic, so far it is working. But the script also does several thing e.g. create system variables on the CCU3:
! Systemvariabel Info ermitteln string Info = ""; if (Wort == "T") { Info = "SensorID: " + TemperatursensorID; } else { Info = stdout.Substr(0,stdout.Find(":")); } !Info = Info.Substr(Wort.Length(), stdout.Length()); !WriteLine("DPInfo = " # Info); !Debug: Welcher DPInfo-Wert wurde gefunden
I'm not shure if this would still work if I would like to add some more sensors in the future (probably yes since I have also created some other variables e.g. 1501 - PPS Präsenztaste).
Maybe ask in FHEM Forum if Bratmaxe would adapt his scripts ?
fredlcore
commented
3 years ago @1coderookie: The thing is that I don't know if there are heating systems which are not going to work with the QAA70. PPS is such a strange protocol and system, that I don't want to make any bets on that. Also, there may be cases where a user has a QAA50 room unit and wants to get into write mode without detaching the QAA50. For that, the bus ID must of course be the one of the QAA50. Plus, there is no extra code for the QAA50. All you would save is the one line text in the webinterface. Yes, if I know 100% that we will never going to use that, I'll get rid of it. Your QAA50 display problem is a different issue and it would be a dirty hack just to get away with the entry without solving any underlying issue first.
With a multiline regex, it would still be possible in the "parameter view" to match the sensor ID with the value.
EDIT: Didn't reply to the other part of your comment: As I said (and as @malansk has confirmed), there is no need for dedicated examples anymore. The sensors behave like any other parameter. So people don't have to think in terms of /T, /B or /A anymore but just in terms of parameter numbers, so the other examples will just fit.
fredlcore
commented
3 years ago @malansk: The Wort == "T" part looks like it needs to be adapted, but I guess this is just the kind of code that also could be left without doing harm because the module should be able to create system variables for "normal" parameters as well (like the Präsenztaste you mentioned). So if you query 20305 there, it should work right away. That's the beauty of this new approach :).
1coderookie
commented
3 years ago Ah ok, I understand that. Btw: so it is possible to let a 'real' room unit be attached to the controller and using writing mode? Because this is what the config.h states: // PPS: // - set 'pps_write' to "1" to enable writing to heater - only use this if there is no other room controller (such as QAA50/QAA70) active.
dukess
commented
3 years ago About sensor sorting https://forum.arduino.cc/index.php?topic=268443.0 "U. D." notifications@github.com 4 декабря 2020 г. 18:35:30 написал:
In any case it should of course be ensured that each sensor stays in its position - at least until new sensors are being added (in case we sort alphabetically or so).
Iirc, the sensors are listed by the alphabetical&numerical order of the specific sensorID. That's why I asked you to add the function of displaying the ID within /T in the past, because without it the sensors just changed the order if any replacement/addition took place and one probably didn't realize right away that the order changed.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.
fredlcore
commented
3 years ago Yes, it is not recommended because you would have to mirror the values in the QAA as well as BSB-LAN and BSB-LAN could then send the QAA70-only functions. Not a widespread scenario, but it may be an option for some.
fredlcore
commented
3 years ago @1coderookie: Could you please check if any of the concrete issues you have raised are still open? Otherwise I would close this issue now. Also, GitHub just informed me that they now offer "Discussions", something like a mini-forum where more general matters and questions can be discussed. If there are still open matters, please let's all open one issue for one thing only. Then it's easier to keep track and know when issues can be closed.
1coderookie
commented
3 years ago QAA-Modell in Webconfig shows QAA70 with one adapter, with another one it shows QAA50 (probably I have to do another /NE on that one - I'll check again in the future), the other problems I mentioned seem to be solved - imo issue can be closed.
malansk
commented
3 years ago For me it also shows QAA70 in the web interface. I have QAA70 also defined in config.h. I never tried to change this to QAA50 in the WEB-UI or in config.h since it would probably rease all my time settings from the heating controller and I would sit in the cold :-)
fredlcore
commented
3 years ago I assume that most of the major aspects in this issue are now fixed. If the QAA-setting bug still exists (or anything else comes up) please open a separate issue for that so we can track it better. Thanks!
Hi guys, I opened this issue as a possibility to report and discuss several problems, probable issues and questions of/about the recent version(s) of BSB-LAN. I hope it's ok for you ;)
@dukess: Because I always had some issues that seemed to only appear within my system (@fredlcore had none of these problems), I just tested the recent version (2.0.14-20201117142051) with a complete fresh system: a not yet used Due and a new EEPROM (straight from the seller). Neither of these had ever contact with BSB-LAN, so I just imitated the absolute 'new' user, who starts over at the first time ever.
I used the default settings of the config.h file, so I didn't change anything there. The flashing itself via Arduino IDE was flawless. After the reboot I switched to the configuration page (url/C). Then I changed two settings via the webinterface:
Because one of the problems in the past was that the settings obviously weren't saved, I clicked on 'Einstellungen' (= settings; url/C) again to see, if the new settings now have been saved.
But: The system doesn't react anymore. The page seems to be loading (judged by the item of the browser tab) and the serial monitor shows "Reading EEPROM..." - but nothing happens anymore since then. See the full output of this sequence of the serial monitor, which stops after 'Reading EEPROM...':
Before I do something like /NE or a reboot now or before I'll describe the other problems I had with my other system in the past, I just wanted to report this behaviour because it already doesn't seem to work as expected.