Läuft: Heizung mit eBus-Schnittstelle

Begonnen von Prof. Dr. Peter Henning, 29 November 2014, 13:36:59

Vorheriges Thema - Nächstes Thema

cs-online

Hallo,

die erste Frage kann ich dir beantworten, weil ich das gerade durch habe: Du brauchst die Version mit MQTT im Dateinamen. Wenn du die hast, dann klappt das schon mal, die habe ich nämlich auch gerade installiert. Wenn du nicht genau weißt, ob deine mit MQTT oder ohne ist, kannst du in der config vom ebusd unter /etc/Default/ebusd mal testweise analog den Eintrag hinten an die EBUSD_OPT anhängen und schauen, ob der dann mit oder ohne Fehler startet, bei mir gab's einen Fehler, weil MQTT nicht im Paket war (hatte die 3.0pre)

--mqttjson --mqtthost=IPVOM EBUSD --mqtttopic=ebusd/%circuit/%name

Grüße

Christian
FHEM auf RPI 4 4GB, HM-WLAN-Gateway, einige HM-Aktoren,2x EBUSD an Heizung+Solar, ESP8266 am Strom-,Gas-,Wasserzähler, in WLAN-Steckdosen und Relaisleisten, Sonoff S20, Shelly1,2 und 2.5,Lacrosse-Gateway und Sensoren,Sduino,Alexa-Fhem,Huawei PV mit Speicher, alles auf einem RPI und da geht noch mehr

Schlauer Det

Christian,

vielen Dank für die schnelle Antwort. Hatte zwar Deine Konversation mit Reinhart und John gelesen, wurde aber daraus nicht so ganz schlau (geht ja gar nicht für den Schlauen Det  ;)).

Hast Du die Version mit mit mqtt0 oder mit mqtt1 genommen?


Cheers
Det  :)

cs-online

#3032
Ich habe das auf dem RPI mit Jessie laufen, also die armhf-Variante und da gabs nur eine mit MQTT...

Wenn du dir aber nicht ganz sicher bist, kannst du hier lesen, wie du per update die richtige Version bekommst und istallierst:

https://github.com/john30/ebusd-debian/blob/master/README.md
FHEM auf RPI 4 4GB, HM-WLAN-Gateway, einige HM-Aktoren,2x EBUSD an Heizung+Solar, ESP8266 am Strom-,Gas-,Wasserzähler, in WLAN-Steckdosen und Relaisleisten, Sonoff S20, Shelly1,2 und 2.5,Lacrosse-Gateway und Sensoren,Sduino,Alexa-Fhem,Huawei PV mit Speicher, alles auf einem RPI und da geht noch mehr

Schlauer Det

Thnx Christian,

mein Raspi läuft auf Stretch und ich sehe gerade, dass es da auch nur eine <ebusd-3.3_armhf-stretch_mqtt1.deb> gibt.
Hatte wohl vorher irgendwie bei den anderen Packages geschaut, wo es auch die Nuller-Versionen für mqtt gibt.
Ist ja alles ziemlich kompliziert für einen alten Mann  ;) ;D


Ciao
Det  :)

Reinhart

Also es kommen "von selbst" nur die Broadcast per MQTT2 an. Wenn du weitere Daten benötigst, verhält sich das gleich wie bei ECMD, also du musst die Daten anfordern.

Das geht bei MQTT so wie im Wiki beschrieben. Also einen "get" Befehl mit deiner Topic und dem gewünschten Datensatz absetzen. Hier ist der Timer auf 10 Minuten gesetzt.


+*00:10:00 set ebusMQTT publish ebusd/430/Hc1HeatCurve/get;
set ebusMQTT publish ebusd/430/HwcTempDesired/get;
set ebusMQTT publish ebusd/bai/WaterPressure/get;
set ebusMQTT publish ebusd/bai/FlowTemp/get;
set ebusMQTT publish ebusd/bai/ReturnTemp/get;
set ebusMQTT publish ebusd/bai/FanSpeed/get;
set ebusMQTT publish ebusd/bai/WPPWMPower/get;
set ebusMQTT publish ebusd/bai/Status02/get;
set ebusMQTT publish ebusd/bai/HcHours/get;
set ebusMQTT publish ebusd/bai/HwcStarts/get

hier ein Beispiel.

Im Prinzip also ähnlich wie bei ECMD nur das Protokoll ist ein anderes und es entfällt natürlich der Perl Code in der erweiterten Utils (bai00.cfg).

LG
FHEM auf Raspy4 mit Bullseye + SSD, Homematic, ESP8266, ESP32, Sonoff, eBus, NanoCUL, MapleCUL, , MQTT2, Alexa

cs-online

hmmm.... aber in der Hilfe vom EBUSD steht doch

--mqttretain           Retain all topics instead of only selected global ones

Ich hätte gedacht, dass dann wirklich alle gesendet werden, ohne dass man die aktiv abfragen muss oder ?

Grüße

Christian
FHEM auf RPI 4 4GB, HM-WLAN-Gateway, einige HM-Aktoren,2x EBUSD an Heizung+Solar, ESP8266 am Strom-,Gas-,Wasserzähler, in WLAN-Steckdosen und Relaisleisten, Sonoff S20, Shelly1,2 und 2.5,Lacrosse-Gateway und Sensoren,Sduino,Alexa-Fhem,Huawei PV mit Speicher, alles auf einem RPI und da geht noch mehr

Schlauer Det

@Reinhart:
Jetzt mischen sich die Beiträge vielleicht etwas. Deshalb mein derzeitiger Stand:

Zitat von: Schlauer Det am 02 Oktober 2019, 09:49:01
Moin eBusd-Gemeinde,

da ich auch vorhabe, auf MQTT2 umzusteigen, weil mir der jetzt bei mir laufende GAEBUS doch zu unflexibel ist (u.a. keine Broadcast-Daten), verfolge ich die letzten Beiträge in diesem Thread mit viel Interesse.

Dabei bleiben bei mir aber noch einige Fragezeichen ?????????

1. Gemäß Wiki EBUS-MQTT2 brauche ich nur einen laufenden eBus-Daemon und eine Anpassung der Config, damit der EBus seine Daten auch an den MQTT2 senden kann. Derzeit läuft bei mir "version: ebusd 3.3.v3.3". Reicht das aus?

Gemäß der Information von Christian (@cs-online) reicht das aber nicht aus und ich brauche einen neuen eBus-Daemon.
In meinem Fall schätze ich mal, dass ich mit dem hier gut bedient bin: https://github.com/john30/ebusd/releases/download/v3.3/ebusd-3.3_armhf-stretch_mqtt1.deb.

Kann das bitte einer der Erfahrungsträger hier im Forum bestätigen?

Zitat
2. Ich möchte mein derzeitiges System an meiner Vaillant EcoCompact zunächst weiter als Produktivsystem auf der bisherigen Implementation laufen lassen und den MQTT2-Teil sowie FHEM auf einem weiteren Raspi realisieren, weil ich das funktionierende System nicht abhängen will, und auch den Ebus für MQTT2 aus topografischen Gründen nicht direkt am Heizgerät nochmal anzapfen kann und will.
Geht das prinzipiell und wie gehe ich dabei am besten vor?

Das bleibt die Nuss, die ich jetzt noch knacken muss:
Wenn ich auf dem zweiten Raspi den neuen eBus-Daemon mit MQTT-Eigenschaft laufen habe, sollte es wohl ausreichen, wenn ich die config entsprechend anspasse, damit die Broadcasts (und mehr brauche ich derzeit für ein proof of concept nicht) über eine IP-Verbindung und den auf Raspi 2 installierten MQTT-Server an FHEM weitergeleitet werden.

Es würde mich sehr freuen, wenn die Spezialisten mir da etwas Unterstützung angedeien lassen könnten.


Cheers aus dem windigen Nordland
Det  :)

cs-online

@Reinhart: Aber einfach nur den Timer mit den Publishes erstellen und laufen lassen bringt mir noch keine Readings mehr:

set MQTT_via_mosquitto publish ebusd/bai/HwcOPMode/get;
set MQTT_via_mosquitto publish ebusd/bai/errorhistory/get;
set MQTT_via_mosquitto publish ebusd/bai/currenterror/get;
set MQTT_via_mosquitto publish ebusd/bai/primarycircuitflowrate/get;
set MQTT_via_mosquitto publish ebusd/bai/wppwmPower/get;
set MQTT_via_mosquitto publish ebusd/bai/HwcHours/get;
set MQTT_via_mosquitto publish ebusd/bai/HcHours/get;
set MQTT_via_mosquitto publish ebusd/bai/Hc1HeatCurve/get;
set MQTT_via_mosquitto publish ebusd/bai/RemainingBoilerblocktime/get;
set MQTT_via_mosquitto publish ebusd/bai/CounterStartattempts2/get;
set MQTT_via_mosquitto publish ebusd/bai/CounterStartattempts1/get;
set MQTT_via_mosquitto publish ebusd/bai/PartloadHwcKW/get;
set MQTT_via_mosquitto publish ebusd/bai/FlowTemp/get;
set MQTT_via_mosquitto publish ebusd/bai/WaterPressure/get;


ich habe es auch hiermit probiert:

+*00:00:30 set myBroker publish ebusd/bai/HwcOPMode/get;
set myBroker publish ebusd/bai/errorhistory/get;
set myBroker publish ebusd/bai/currenterror/get;
set myBroker publish ebusd/bai/primarycircuitflowrate/get;
set myBroker publish ebusd/bai/wppwmPower/get;
set myBroker publish ebusd/bai/HwcHours/get;
set myBroker publish ebusd/bai/HcHours/get;
set myBroker publish ebusd/bai/Hc1HeatCurve/get;
set myBroker publish ebusd/bai/RemainingBoilerblocktime/get;
set myBroker publish ebusd/bai/CounterStartattempts2/get;
set myBroker publish ebusd/bai/CounterStartattempts1/get;
set myBroker publish ebusd/bai/PartloadHwcKW/get;
set myBroker publish ebusd/bai/FlowTemp/get;
set myBroker publish ebusd/bai/WaterPressure/get


Was muss ich denn nun wirklich tun, damit zumindest alle relevanten Readings ankommen ?
FHEM auf RPI 4 4GB, HM-WLAN-Gateway, einige HM-Aktoren,2x EBUSD an Heizung+Solar, ESP8266 am Strom-,Gas-,Wasserzähler, in WLAN-Steckdosen und Relaisleisten, Sonoff S20, Shelly1,2 und 2.5,Lacrosse-Gateway und Sensoren,Sduino,Alexa-Fhem,Huawei PV mit Speicher, alles auf einem RPI und da geht noch mehr

john30

Zitat von: cs-online am 02 Oktober 2019, 19:49:45
hmmm.... aber in der Hilfe vom EBUSD steht doch

--mqttretain           Retain all topics instead of only selected global ones

Ich hätte gedacht, dass dann wirklich alle gesendet werden, ohne dass man die aktiv abfragen muss oder ?
das hat damit gar nichts zu tun. Hier geht es nur darum, wie ebusd die Nachrichten an den MQTT Broker weiterleitet. Mittels retain sagt ebusd dem Broker, dass er alle Nachrichten für immer behalten soll, bis ebusd was anderes sagt.
author of ebusd

cs-online

OK, das hatte ich anders verstanden. MQTT ist nicht meins, sorry... Gibt's denn eine Möglichkeit, in kurzen Abständen alle Werte zu aktualisieren und zu senden ? Und gibt's auf der FHEM-Seite noch andere Möglichkeiten, als über Timer zu aktualisieren ? Das führt bei mir nämlich zu ähnlichen Freeze-Zeiten wie über ECMD... dabei für mich mal zum besseren Verständnis ein paar Fragen:

- wie lange dauert eigentlich ein Zyklus auf dem Bus, bis alle Werte einmal durchlaufen sind ?
- wenn in der CSV r1 angezogen ist, dann müsste doch bei jedem Zyklus der Wert refresht werden oder ? Wenn ich aber mit Find -d dann alle Daten abziehe, sind die teilweise schon mehrere Minuten alt
- gibt es einen Befehl, mit dem man r -f für alle Werte auf einmal aufrufen kann ?
FHEM auf RPI 4 4GB, HM-WLAN-Gateway, einige HM-Aktoren,2x EBUSD an Heizung+Solar, ESP8266 am Strom-,Gas-,Wasserzähler, in WLAN-Steckdosen und Relaisleisten, Sonoff S20, Shelly1,2 und 2.5,Lacrosse-Gateway und Sensoren,Sduino,Alexa-Fhem,Huawei PV mit Speicher, alles auf einem RPI und da geht noch mehr

Reinhart

mach es doch einmal schrittweise und erzähle was jetzt bei dir unter MQTT2 schon läuft.
Hast du den MQTT2 Server oder MQTT2 Client aktiviert? Hast du die Topic gesetzt und was legt "autocreate" an?  Welche MQTT2_Devices werden automatisch angelegt? Es müssen zumindest alle Devices automatisch angelegt worden sein die über Broadcasts kommen.
Wenn die MQTT2_Server hast (also ohne Mosquitto), wie hast du den autocreate eingestellt (no, simple oder complex). Diese Einstellung ist primär entscheidend für die Readings die dann angelegt werden sollen. Ich empfehle dir "complex" zu verwenden, sonst kannst du Status01 und Status02 nicht unterscheiden.

Eigentlich sind es ja nur wenige Schritte (siehe Wiki) die notwendig sind das die Devices automatisch angelegt werden, erst wenn die Basis funktioniert kannst du dir Gedanken über die Abfragen machen und da auch überlegen was wirklich notwendig ist. Es macht ja nicht viel Sinn die gesamte Brennerlaufzeit alle 2 Minuten abzufragen, einmal am Tag ist doch da genug. Wobei der Vorlauf ist da schon interessanter und der kommt eh automatisch über den Broadcast an.

Es gibt beim eBus keinen zyklischen "Durchlauf", was sollte das der Kommunikation der Geräte untereinander bringen. Es kommen nur jede Daten über den Bus die gerade für Steuerzwecke dem anderen Gerät mitgeteilt werden. zB: ein interner Timer wird aktiv oder ein Alarm tritt auf. Wenn du am Steuergerät (Calormatic etc.) hantierst, werden eben mehr Daten über den Bus kommen, je nachdem was du da einstellst.

LG
FHEM auf Raspy4 mit Bullseye + SSD, Homematic, ESP8266, ESP32, Sonoff, eBus, NanoCUL, MapleCUL, , MQTT2, Alexa

cs-online

Zitat von: Reinhart am 03 Oktober 2019, 20:15:58
mach es doch einmal schrittweise und erzähle was jetzt bei dir unter MQTT2 schon läuft.
Hast du den MQTT2 Server oder MQTT2 Client aktiviert? Hast du die Topic gesetzt und was legt "autocreate" an?  Welche MQTT2_Devices werden automatisch angelegt? Es müssen zumindest alle Devices automatisch angelegt worden sein die über Broadcasts kommen.
Wenn die MQTT2_Server hast (also ohne Mosquitto), wie hast du den autocreate eingestellt (no, simple oder complex). Diese Einstellung ist primär entscheidend für die Readings die dann angelegt werden sollen. Ich empfehle dir "complex" zu verwenden, sonst kannst du Status01 und Status02 nicht unterscheiden.

Eigentlich sind es ja nur wenige Schritte (siehe Wiki) die notwendig sind das die Devices automatisch angelegt werden, erst wenn die Basis funktioniert kannst du dir Gedanken über die Abfragen machen und da auch überlegen was wirklich notwendig ist. Es macht ja nicht viel Sinn die gesamte Brennerlaufzeit alle 2 Minuten abzufragen, einmal am Tag ist doch da genug. Wobei der Vorlauf ist da schon interessanter und der kommt eh automatisch über den Broadcast an.

Es gibt beim eBus keinen zyklischen "Durchlauf", was sollte das der Kommunikation der Geräte untereinander bringen. Es kommen nur jede Daten über den Bus die gerade für Steuerzwecke dem anderen Gerät mitgeteilt werden. zB: ein interner Timer wird aktiv oder ein Alarm tritt auf. Wenn du am Steuergerät (Calormatic etc.) hantierst, werden eben mehr Daten über den Bus kommen, je nachdem was du da einstellst.

LG

ich versuche mal Antworten auf deine Fragen zu finden:

- ich habe den MQTT-Broker (DEF: myBroker MQTT 127.0.0.1:1883), MQTT_via_mosquitto (defmod MQTT_via_mosquitto MQTT2_CLIENT 127.0.0.1:1883
attr MQTT_via_mosquitto autocreate complex) und MQTT2_ebusd, das ist wie folgt definiert:

defmod MQTT2_ebusd MQTT2_DEVICE ebusd
attr MQTT2_ebusd DbLogInclude *
attr MQTT2_ebusd IODev MQTT_via_mosquitto
attr MQTT2_ebusd autocreate 1
attr MQTT2_ebusd bridgeRegexp (ebus..*?)/(bai|\d+|cc|e7f|ehp|f\d\d|hc|he.|hmu|hwc|mc|mc.\d|omu|omu.\d|pms|rcc|rcc.\d|sc|sdr_p|ui|uih|v\d\d|v81.\d|vd\d|vl\d|vr_\d\d|zeo)/.*:.* "$1_$2"\
(ebus..*?)/(global|broadcast|general|scan([^/]*))/.*:.* "$1"
attr MQTT2_ebusd devStateIcon 1.true:it_net 1.false:it_net@red  2.true:lan_rs485 2.false:lan_rs485@red
attr MQTT2_ebusd group MQTT
attr MQTT2_ebusd icon sani_boiler_temp
attr MQTT2_ebusd model eBus_daemon_splitter
attr MQTT2_ebusd readingList ebusd/global/uptime:.* uptime\
ebusd/global/running:.* running\
ebusd/global/version:.* version\
ebusd/scan\.08/:.* { json2nameValue($EVENT, 'scan.08_', $JSONMAP) }\
ebusd/scan\.15/:.* { json2nameValue($EVENT, 'scan.15_', $JSONMAP) }\
ebusd/global/signal:.* signal\
ebusd/global/updatecheck:.* updatecheck\
ebusd/broadcast/vdatetime:.* { json2nameValue($EVENT, 'vdatetime_', $JSONMAP) }\
ebusd/broadcast/outsidetemp:.* { json2nameValue($EVENT, 'outsidetemp_', $JSONMAP) }\

attr MQTT2_ebusd room Schnittstellen
attr MQTT2_ebusd setList getKnown:noArg ebusd/list\
  getAll:noArg ebusd/list
attr MQTT2_ebusd stateFormat Status: \
1:running\
Signal: \
2:signal\
<br>Uptime: formatedUptime
attr MQTT2_ebusd userReadings formatedUptime:uptime.* {my $m = ReadingsVal($name,"uptime",0)/60;;;; return sprintf "0 000 00:%02d", $m if $m < 60;;;; my $h = $m / 60;;;; $m %= 60;;;; return sprintf "0 000 %02d:%02d", $h, $m if $h < 24;;;; my $d = $h / 24;;;; $h %= 24;;;; return sprintf "0 %03d %02d:%02d", $d, $h, $m if $d <365;;;; my $y = $d / 365;;;; $d %= 365;;;; return sprintf "%d %03d %02d:%02d", $y, $d, $h, $m}


Also alles im Prinzip streng nach Wiki.

Diese Readings kamen "automatisch"

running
true
2019-10-03 07:26:27
scan.08_HW_value
7401
2019-10-03 07:26:27
scan.08_ID_value
BAI00
2019-10-03 07:26:27
scan.08_MF_value
Vaillant
2019-10-03 07:26:27
scan.08_SW_value
0703
2019-10-03 07:26:27
scan.15_HW_value
6002
2019-10-01 20:21:21
scan.15_ID_value
47000
2019-10-01 20:21:21
scan.15_MF_value
Vaillant
2019-10-01 20:21:21
scan.15_SW_value
0126
2019-10-01 20:21:21
signal
true
2019-10-03 07:26:27
state
getAll
2019-10-02 21:19:17
updatecheck
"revision v3.3-4-g212b22d available, broadcast.csv: newer version available, vaillant/08.bai.csv: newer version available, vaillant/15.470.csv: newer version available, vaillant/bai.0010004121.inc: different version available, vaillant/broadcast.csv: different version available, vaillant/errors.inc: newer version available, vaillant/hcmode.inc: newer version available"
2019-10-03 07:26:27
uptime
92394
2019-10-03 20:56:03
vdatetime_date_value
03.10.2019
2019-10-03 20:54:51
vdatetime_time_value
20:54:50
2019-10-03 20:54:51
version
"ebusd 3.3.v3.3"


Angelegt wurde ein MQTT2-Device "MQTT2_ebusd_bai", das hat folgende Readings:

setstate MQTT2_ebusd_bai 2019-10-03 21:00:07 DateTime_bdate_value 03.10.2019
setstate MQTT2_ebusd_bai 2019-10-03 21:00:07 DateTime_btime_value 21:00:04
setstate MQTT2_ebusd_bai 2019-10-03 21:00:07 DateTime_dcfstate_value valid
setstate MQTT2_ebusd_bai 2019-10-03 21:00:07 DateTime_temp2_value 12.062
setstate MQTT2_ebusd_bai 2019-10-03 21:07:43 IonisationVoltageLevel_0_name
setstate MQTT2_ebusd_bai 2019-10-03 21:07:43 IonisationVoltageLevel_0_value 74.4
setstate MQTT2_ebusd_bai 2019-10-03 21:00:32 OutdoorstempSensor_sensor_value ok
setstate MQTT2_ebusd_bai 2019-10-03 21:00:32 OutdoorstempSensor_temp_value 12.06
setstate MQTT2_ebusd_bai 2019-10-03 21:10:36 PrimaryCircuitFlowrate_0_name
setstate MQTT2_ebusd_bai 2019-10-03 21:10:36 PrimaryCircuitFlowrate_0_value 1352
setstate MQTT2_ebusd_bai 2019-10-03 20:59:21 Status01_0_name temp1
setstate MQTT2_ebusd_bai 2019-10-03 20:59:21 Status01_0_value 24.0
setstate MQTT2_ebusd_bai 2019-10-03 20:59:21 Status01_1_name temp1
setstate MQTT2_ebusd_bai 2019-10-03 20:59:21 Status01_1_value 24.0
setstate MQTT2_ebusd_bai 2019-10-03 20:59:21 Status01_2_name temp2
setstate MQTT2_ebusd_bai 2019-10-03 20:59:21 Status01_2_value 12.062
setstate MQTT2_ebusd_bai 2019-10-03 20:59:21 Status01_3_name temp1
setstate MQTT2_ebusd_bai 2019-10-03 20:59:21 Status01_4_name temp1
setstate MQTT2_ebusd_bai 2019-10-03 20:59:21 Status01_4_value 29.0
setstate MQTT2_ebusd_bai 2019-10-03 20:59:21 Status01_5_name pumpstate
setstate MQTT2_ebusd_bai 2019-10-03 20:59:21 Status01_5_value off
setstate MQTT2_ebusd_bai 2019-10-03 21:00:32 associatedWith MQTT2_ebusd2


Die Readings kommen nun ohne den Timer sporadisch, mit Timer freezed das System genauso wie mit dem ECMD-Devices.

Ich bräuchte diese Werte kurzzyklisch, sagen wir mal mindestens alle 30 Sekunden, um ein Problem, das es mit der Anlage gibt, weiter eingrenzen zu können:
- Soll, Vor- und Rücklauf
- Ionisationsspannung und ein paar andere interne Werte
- Volumenstrom um darüber die tatsächlich abgegebene Leistung zu berechnen
- Speichertemperaturen vom Solarspeicher oben und unten.

Alles andere könnte wegen mir ca.10 Minütlich kommen.

Lt. Doku fragt EBUSD doch aktiv diejenigen Werte ab, bei denen man eine Prio von 1-9 vergibt, also z.B. r1 (soll dann den Wert bei jedem Zyklus abfragen, daher die Frage, wie lange denn ein Zyklus wäre, weil das bei mir u.U. mehrere Minuten dauert, bis neue Daten kommen)

Deshalb war das Skript mit dem Find -d von dir schon super, das habe ich dann in Readings splitten lassen. Wenn nun also damit im Bereich von ca. 30 Sekunden Daten gekommen wären, wäre das super gewesen... Für "ich schau mal, was es alles gibt" reicht das für normale User sicher aus, aber für die Fehlereingrenzung reicht das leider gar nicht, weil die Anlage teilweise schon wieder abschaltet, bevor Werte angekommen sind.

Also bleibt die Frage: Wie bekomme ich EBUSD dazu, mindestens mal die wichtigen Werte kurzzyklisch zu aktualisieren ohne FHEM zu blocken ?

Und bevor ich es vergesse und ein falscher Eindruck entsteht: Ich bin besonders euch beiden sehr dankbar, dass Ihr versucht zu helfen !!!

Grüße Christian
FHEM auf RPI 4 4GB, HM-WLAN-Gateway, einige HM-Aktoren,2x EBUSD an Heizung+Solar, ESP8266 am Strom-,Gas-,Wasserzähler, in WLAN-Steckdosen und Relaisleisten, Sonoff S20, Shelly1,2 und 2.5,Lacrosse-Gateway und Sensoren,Sduino,Alexa-Fhem,Huawei PV mit Speicher, alles auf einem RPI und da geht noch mehr

Reinhart

ah, sehr schön, da funktioniert eh schon sehr viel.
Wenn du dann später einfach auf MQTT2_Server umsteigst und den Mosquitto deaktivierst dann hast eh alles auf MQTT2.

Warum du bei der Timerabfrage jetzt Freezer bekommst kann ich dir auch nicht sagen. Da du die Daten für deine Recherche benötigst, nehme ich an du Logst die fleißig in eine DB. Vielleicht einmal "plotfork 1" in der WEB define setzen.  Ich kenne jetzt deine Umgebung nicht, aber wenn du da einen eigenen Raspi hast, kannst ja dort entweder ein Abfragescript per ebusctl oder eine kleine Fheminstanz mit genau den Timern die du brauchst konfigurieren und schauen ob es da auch so schlimm mit den Freezern ist.
Ich habe das jetzt bei mir mit den Timern ein paarmal hintereinander getestet, bekomme aber keine Freezer. Hast du die Freezer auch, wenn du das Kommando direkt in der Fhem Kommandozeile eingibst ( zB: "set ebusMQTT publish ebusd/430/HwcTempDesired/get" ) ?

LG
FHEM auf Raspy4 mit Bullseye + SSD, Homematic, ESP8266, ESP32, Sonoff, eBus, NanoCUL, MapleCUL, , MQTT2, Alexa

cs-online

...ja es wird in eine DB geloggt (seit kurzem), die auf einem NAS liegt, das spart schon mal Rechenleistung auf dem RASPI, auf dem ansonsten alles drauf läuft, also 2x EBUS-Adapter mit jeweils EBUSD, HM-Gateway, Lacrosse-Gateway, Culs und Signaduinos, Alexa und und und.... daher sind Freeze-Zeiten dann recht störend... Ich habe jetzt mal testweise die wichtigsten Werte über ein bash-Skript, das ich aktuell noch über einen Timer aus FHEM heraus triggere, abgefragt. Dann kann ich im gleichen Takt die find -d Geschichte abfragen. Da habe ich alle relevanten Readings drin und im Moment sieht das noch recht gut aus... Ich teste mal weiter...

Danke für deine Anregungen !!!

BTW (OT): Ich war mal am überlegen, meinen RPI2B gegen einen 4er mit 4GB zu tauschen, aber die Berichte, dass der recht heiss würde und mehr Strom ziehen würde, haben mich bislang abgehalten. In deiner Signatur steht, dass du einen 4er hast, wie sind deine Erfahrungen ?
FHEM auf RPI 4 4GB, HM-WLAN-Gateway, einige HM-Aktoren,2x EBUSD an Heizung+Solar, ESP8266 am Strom-,Gas-,Wasserzähler, in WLAN-Steckdosen und Relaisleisten, Sonoff S20, Shelly1,2 und 2.5,Lacrosse-Gateway und Sensoren,Sduino,Alexa-Fhem,Huawei PV mit Speicher, alles auf einem RPI und da geht noch mehr

Reinhart

FHEM auf Raspy4 mit Bullseye + SSD, Homematic, ESP8266, ESP32, Sonoff, eBus, NanoCUL, MapleCUL, , MQTT2, Alexa