[Gelöst] Topic vom ebusd via MQTT verändert sich laufend

Begonnen von kptkip, 14 August 2020, 15:05:14

Vorheriges Thema - Nächstes Thema

kptkip

Hallo,

ich habe meinen ebusd mit folgender Angabe:
EBUSD_OPTS="--scanconfig --accesslevel=* --mqttport=1884 --mqttjson --mqtthost=[FHEMIP] --mqtttopic=ebusd/%circuit/%name"
in der /etc/default/ebusd mit MQTT ausgestattet.

Per MQTT_SERVER2 habe ich das Teil auch in Fhem am Laufen. Soweit so gut.

Das Problem ist nur, dass bei mir das Topic nicht
ebusd/...
heißt, sondern
ebusd_3.4_26415/...

Die angehängte Zahlenfolge baut mir das System aus der Programm-Versionsnummer und der "Main PID: 26415 (ebusd)" des ebusD-Prozesses zusammen.

Das geht solange gut, bis ich den Raspi neustarte, den ebusd neustarte, Updates fahre oder Ähnliches.

Dann habe ich nicht nur ein neues topic in MQTT sondern auch auf einmal ein neues MQTT2-Device im System und das alte tut nicht mehr, weil das topic nicht mehr stimmt.

Kennt das Phänomen jemand und wie kann ich das Topic statisch bekommen - ohne PID-Nummern oder Ähnliches?

Gruß
Alex
FHEM Revision: 22312 auf RasPI3B+,1xNeumannCUL,HMLAN,1xRasPi3B+,2xRasPI ZERO W
CUL_HM:HM-Sec-SCo, HM-CC-RT-DN
Fritz: Fritz!Box 6590C,DECT301,DECT200
Shelly:Shelly1,Shelly2, ShellyBulb Xiaomi: Schalter, Fensterkontakte HUE: ConbeeII
Tasmota:SonoffBridge, Stecker

rudolfkoenig

Ich wuesste gerne, warum der ebusd Entwickler diese Infos an dieser Stelle eingebaut hat.

In FHEM kann man das Problem mit einem passenden Regexp in dem readingsList loesen.

Beta-User

#2
?
Irgendwas scheint mir hier anders zu sein als bei den vermutlich Dutzenden anderer User, die das stressfrei (und nach denselben Vorgaben aus dem Wiki) nutzen. Ich kann mich allerdings entsinnen, während der Tests mit dem System, das mir jemand anderes da zur remote-Verfügung gestellt hatte, auch manchmal solche Topic-Pfade erhalten zu haben, ohne restlos aufklären zu können, wo das herkam.

Die ersten Fragen wäre daher: FHEM ist aktuell? Und der ebus-Dienst ebenso?

Gibt es evtl. Verbindungsabbrüche?

EDIT: Und liefere bitte auch ein RAW vom zentralen ebus-MQTT2-Device. Evtl. ist da was verbogen.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

kptkip

Hallo,

anbei mein List vom MQTT2-Server Device:
Internals:
   CONNECTS   712
   DEF        1884 global
   FD         33
   FUUID      5dd05b78-f33f-57e4-55c0-229e0beff67e95ee
   NAME       Mosquitto2
   NR         237
   PORT       1884
   STATE      Initialized
   TYPE       MQTT2_SERVER
   READINGS:
     2020-08-16 09:22:53   RETAIN          {"/Smarthome/DR/Garten/Terasse/tele/LWT":"Online","/Smarthome/DR/Garten/tasmota/tele/LWT":"Offline","/Smarthome/Dach/Buero/SonoffS20_1/tele/LWT":"Offline","/Smarthome/EG/Kueche/Kaffeemaschine/tele/LWT":"Online","/Smarthome/EG/Kueche/tasmota/tele/LWT":"Online","/Smarthome/KG/Waschkueche/Trockner/tele/LWT":"Online","/Smarthome/Keller/Waschkueche/Waschmaschine/tele/LWT":"Online","/Smarthome/OG/Elternbad/Handtuchheizung/tele/LWT":"Online","/Smarthome/OG/Gretabad/Handtuchheizung_Greta/tele/LWT":"Online","/Sonoff/Bridge/tele/LWT":"Online","/Sonoff/BridgeKeller/tele/LWT":"Online","ebusd/global/running":"false","ebusd/global/signal":"true","ebusd/global/updatecheck":"\u0022revision v3.4 available\u0022","ebusd/global/version":"\u0022ebusd 3.4.v3.3-51-g57eae05\u0022"}
     2020-07-24 08:17:52   lastPublish     /Smarthome/EG/Kueche/Kaffeemaschine/cmnd/Backlog:StateText1 off; StateText2 on; StateText3 toggle; StateText4 hold; SetOption26 1; SaveData 1
     2020-08-16 11:26:18   nrclients       19
     2020-08-11 10:44:29   state           Initialized
   clients:
     Mosquitto2_127.0.0.1_42070 1
   retain:
     ebusd/global/running:
       ts         1597418846.51387
       val        false
     ebusd/global/signal:
       ts         1597418422.65139
       val        true
     ebusd/global/updatecheck:
       ts         1597407776.6049
       val        "revision v3.4 available"
     ebusd/global/version:
       ts         1597407638.95156
       val        "ebusd 3.4.v3.3-51-g57eae05"
Attributes:
   DbLogExclude .*
   autocreate complex
   group      Infrastruktur
   icon       it_wifi
   room       Infrastruktur->MQTT,Infrastruktur->Serverschrank[/code

Fhem und ebusd sind up to date.

Gruß
Alex
FHEM Revision: 22312 auf RasPI3B+,1xNeumannCUL,HMLAN,1xRasPi3B+,2xRasPI ZERO W
CUL_HM:HM-Sec-SCo, HM-CC-RT-DN
Fritz: Fritz!Box 6590C,DECT301,DECT200
Shelly:Shelly1,Shelly2, ShellyBulb Xiaomi: Schalter, Fensterkontakte HUE: ConbeeII
Tasmota:SonoffBridge, Stecker

Beta-User

Lustig, einen MQTT2_SERVER "mosquitto" zu nennen...

Ich meinte aber eigentlich nicht das SERVER-Device, sondern das zentrale Ebus-Device (das mit der bridgeRegexp).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

kptkip

 :)

Ich habe mittlerweile etwas geändert. In der Readingslist habe ich den String

ebusd_3.4_26415:ebusd/...
in
ebusd/
geändert.

Seither gibt es das Problem im Device nicht mehr. Allerdings kam diese Einstellung ursprünglich aus einem MQTT-Template.


Hier das nun funktionierende Device:
Internals:
   CFGFN     
   CID        ebusd_3.4_17971
   DEF        ebusd_3.4_17971
   DEVICETOPIC MQTT2_ebusd_3.4_1714
   FUUID      5f38ff5f-f33f-56af-6d95-9b40d7c23d2e3399
   IODev      Mosquitto2
   LASTInputDev Mosquitto2
   MSGCNT     610
   Mosquitto2_MSGCNT 610
   Mosquitto2_TIME 2020-08-16 12:39:15
   NAME       MQTT2_ebusd_3.4_1714
   NR         26491
   STATE      ???
   TYPE       MQTT2_DEVICE
   JSONMAP:
     Status01_0_value _Vorlauf
     Status01_1_value _Ruecklauf
     Status01_2_value _Aussentemp
     Status01_3_value _Warmwasser
     Status01_4_value _WWSpeicher
     Status01_5_value _Pumpenstatus
     Status02_0_value _HWCMode
     Status02_1_value _Maximaltemperatur
     Status02_2_value _ReglerMaxTEMP
     Status02_3_value _ReglerCurrentTemp
   READINGS:
     2020-08-16 12:38:55   DateTime_bdate_value -.-.-
     2020-08-16 12:38:55   DateTime_btime_value 11:24:30
     2020-08-16 12:38:55   DateTime_dcfstate_value nosignal
     2020-08-16 12:38:55   DateTime_temp2_value 25.438
     2020-08-16 12:39:15   Status01_0_name temp1
     2020-08-16 11:51:19   Status01_0_value 43.0
     2020-08-16 12:39:15   Status01_1_name temp1
     2020-08-16 11:51:19   Status01_1_value 42.0
     2020-08-16 12:39:15   Status01_2_name temp2
     2020-08-16 11:51:19   Status01_2_value 25.062
     2020-08-16 12:39:15   Status01_3_name temp1
     2020-08-16 11:51:19   Status01_3_value 43.0
     2020-08-16 12:39:15   Status01_4_name temp1
     2020-08-16 11:51:19   Status01_4_value 56.0
     2020-08-16 12:39:15   Status01_5_name pumpstate
     2020-08-16 11:51:19   Status01_5_value off
     2020-08-16 12:38:45   Status02_0_name hwcmode
     2020-08-16 11:50:54   Status02_0_value off
     2020-08-16 12:38:45   Status02_1_name temp0
     2020-08-16 11:50:54   Status02_1_value 60
     2020-08-16 12:38:45   Status02_2_name temp1
     2020-08-16 11:50:54   Status02_2_value 30.0
     2020-08-16 12:38:45   Status02_3_name temp0
     2020-08-16 11:50:54   Status02_3_value 80
     2020-08-16 12:38:45   Status02_4_name temp1
     2020-08-16 12:38:45   Status02_4_value 55.0
     2020-08-16 12:39:15   _Aussentemp     25.438
     2020-08-16 12:38:45   _HWCMode        off
     2020-08-16 12:38:45   _Maximaltemperatur 60
     2020-08-16 12:39:15   _Pumpenstatus   off
     2020-08-16 12:38:45   _ReglerCurrentTemp 80
     2020-08-16 12:38:45   _ReglerMaxTEMP  30.0
     2020-08-16 12:39:15   _Ruecklauf      49.0
     2020-08-16 12:39:15   _Vorlauf        51.0
     2020-08-16 12:39:15   _WWSpeicher     55.0
     2020-08-16 12:39:15   _Warmwasser     48.0
     2020-08-16 11:41:52   running         true
     2020-08-16 11:42:07   signal          true
     2020-08-16 11:44:09   updatecheck     "revision v3.4 available"
     2020-08-16 12:39:15   vdatetime_date_value 16.08.2020
     2020-08-16 12:39:15   vdatetime_time_value 12:35:08
     2020-08-16 11:41:51   version         "ebusd 3.4.v3.3-51-g57eae05"
Attributes:
   DbLogExclude .*
   IODev      Mosquitto2
   alias      ! Vaillant Heizung MQTT
   devStateIcon {
my $vV = ReadingsVal($name, "_Vorlauf", "");
my $colVor = substr(Color::pahColor(20,40,60,$vV,0),0,6);
my $iconVor = 'sani_supply_temp@'.$colVor;

my $vR = ReadingsVal($name, "_Ruecklauf", "");
my $colRueck = substr(Color::pahColor(20,40,60,$vR,0),0,6);
my $iconRueck = 'sani_return_temp@'.$colRueck;

my $vW = ReadingsVal($name, "_Warmwasser", "");
my $colWarm = substr(Color::pahColor(20,40,60,$vW,0),0,6);
my $iconWarm = 'sani_water_hot@'.$colWarm;

my $vA = ReadingsVal($name, "_Aussentemp", "");
my $colAussen = substr(Color::pahColor(-10,10,30,$vA,0),0,6);
my $iconAussen = 'temp_outside@'.$colAussen; ;

my $vC = ReadingsVal($name, "Hc1HeatCurve_curve_value", "");
my $colCurve = substr(Color::pahColor(-10,10,30,$vC,0),0,6);
my $iconCurve = 'measure_current@'.$colCurve; ;

my $vF = ReadingsVal($name, "Flame_0_value", "");
my $colFlame = substr(Color::pahColor(-10,10,30,$vC,0),0,6);
my $iconFlame = 'secur_smoke_detector@'.$colFlame; ;

my $vD = ReadingsVal($name, "WaterPressure_press_value", "0");
my $colDruck = substr(Color::pahColor(0,1,2,$vD,0),0,6);
my $iconDruck = 'weather_barometric_pressure@'.$colDruck; ;

"<div style=\"text-align:right\" > Vorlauf: " .
FW_makeImage("$iconVor",'file_unknown@grey') . "<span style='display: inline-block; width:80px'> $vV °C</span><br>Ruecklauf: " .
FW_makeImage("$iconRueck",'file_unknown@grey') . "<span style='display: inline-block; width:80px'> $vR °C</span><br>Warmwasser: " .
FW_makeImage("$iconWarm",'file_unknown@grey') . "<span style='display: inline-block; width:80px'> $vW °C</span><br>Aussentemp: " .
FW_makeImage("$iconAussen",'file_unknown@grey') . " <span style='display: inline-block; width:80px'>" . int($vA*10)/10 . "°C</span><br>Heizkurve: " .
FW_makeImage("$iconCurve",'file_unknown@grey') . " <span style='display: inline-block; width:80px'>" . int($vC*10)/10 . "</span><br>Heizflamme: " .
FW_makeImage("$iconFlame",'file_unknown@grey') . " <span style='display: inline-block; width:80px'>" . $vF . "</span></div>" .
"<div style=\"text-align:right\" > Wasserdruck: " .
FW_makeImage("$iconDruck",'file_unknown@grey') . "<span style='display: inline-block; width:80px'>" . int($vD*100)/100 . " Bar</span></div>"
}
   genericDeviceType TemperatureSensor
   homebridgeMapping CurrentTemperature=_Aussentemp
   icon       sani_boiler_temp
   jsonMap    Status01_0_value:_Vorlauf Status01_1_value:_Ruecklauf Status01_2_value:_Aussentemp Status01_3_value:_Warmwasser Status01_4_value:_WWSpeicher Status01_5_value:_Pumpenstatus Status02_0_value:_HWCMode Status02_1_value:_Maximaltemperatur Status02_2_value:_ReglerMaxTEMP Status02_3_value:_ReglerCurrentTemp
   readingList ebusd/global/version:.* version
ebusd/global/running:.* running
ebusd/scan\x5c\x2e08/:.* { json2nameValue($EVENT, 'scan.08_', $JSONMAP) }
ebusd/scan\x5c\x2e08/id:.* { json2nameValue($EVENT, 'id_', $JSONMAP) }
ebusd/global/signal:.* signal
ebusd/scan\x5c\x2e15/:.* { json2nameValue($EVENT, 'scan.15_', $JSONMAP) }
ebusd/scan\x5c\x2e15/id:.* { json2nameValue($EVENT, 'id_', $JSONMAP) }
ebusd/bai/DateTime:.* { json2nameValue($EVENT, 'DateTime_', $JSONMAP) }
ebusd/bai/Status01:.* { json2nameValue($EVENT, 'Status01_', $JSONMAP) }
ebusd/bai/Status02:.* { json2nameValue($EVENT, 'Status02_', $JSONMAP) }
ebusd/430/Hc1HcType:.* { json2nameValue($EVENT, 'Hc1HcType_', $JSONMAP) }
ebusd/430/Hc1ActualFlowTempDesired:.* { json2nameValue($EVENT, 'Hc1ActualFlowTempDesired_', $JSONMAP) }
ebusd/430/BMUB51101StorageTemp:.* { json2nameValue($EVENT, 'BMUB51101StorageTemp_', $JSONMAP) }
ebusd/bai/WaterPressure:.* { json2nameValue($EVENT, 'WaterPressure_', $JSONMAP) }
ebusd/bai/Flame:.* { json2nameValue($EVENT, 'Flame_', $JSONMAP) }
ebusd/bai/OutdoorstempSensor:.* { json2nameValue($EVENT, 'OutdoorstempSensor_', $JSONMAP) }
ebusd/430/Hc1HeatCurve:.* { json2nameValue($EVENT, 'Hc1HeatCurve_', $JSONMAP) }
ebusd/bai/FlowTemp:.* { json2nameValue($EVENT, 'FlowTemp_', $JSONMAP) }
ebusd/bai/ReturnTemp:.* { json2nameValue($EVENT, 'ReturnTemp_', $JSONMAP) }
ebusd/430/Hc1Pump:.* { json2nameValue($EVENT, 'Hc1Pump_', $JSONMAP) }
ebusd/broadcast/vdatetime:.* { json2nameValue($EVENT, 'vdatetime_', $JSONMAP) }
ebusd/global/updatecheck:.* updatecheck
ebusd/global/updatecheck:.* updatecheck
   room       Homekit,Infrastruktur->Heizung,Infrastruktur->MQTT
FHEM Revision: 22312 auf RasPI3B+,1xNeumannCUL,HMLAN,1xRasPi3B+,2xRasPI ZERO W
CUL_HM:HM-Sec-SCo, HM-CC-RT-DN
Fritz: Fritz!Box 6590C,DECT301,DECT200
Shelly:Shelly1,Shelly2, ShellyBulb Xiaomi: Schalter, Fensterkontakte HUE: ConbeeII
Tasmota:SonoffBridge, Stecker

Beta-User

Hm, das sieht eigentlich nicht wie ein Device aus, dass das Basis-Template für den Ebus (eBus_daemon_splitter) erzeugt...

Es gibt in den Praxisbeispielen auch einen kurzen Abschnitt zu ebus und einen weiteren Artikel.
Aber wenn es funktioniert...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

kptkip

Stimmt, ich hab da einiges noch erweitert - gerade im devstatIcon-Bereich.

Was mich allerdings jetzt doch noch wundert ist, dass mir 3 Werte fehlen (Leitungsdruck, Heizflamme und die Heizkurve).

Die hatte ich bis vorgestern noch empfangen. Habe nun auch den MQTT.fx bemüht. Dort kommen die Werte auch nicht an.

Seltsamerweise in meinem GAEBUS-Device (eigentlich als Fallback gedacht) sind sie drin. Das heißt der ebusd hat die Werte schon im Bauch - liefert sie per MQTT aber nicht aus.
FHEM Revision: 22312 auf RasPI3B+,1xNeumannCUL,HMLAN,1xRasPi3B+,2xRasPI ZERO W
CUL_HM:HM-Sec-SCo, HM-CC-RT-DN
Fritz: Fritz!Box 6590C,DECT301,DECT200
Shelly:Shelly1,Shelly2, ShellyBulb Xiaomi: Schalter, Fensterkontakte HUE: ConbeeII
Tasmota:SonoffBridge, Stecker

TomLee

ZitatLeitungsdruck, Heizflamme und die Heizkurve

Ist eventuell das AT, welches die Daten anfordert,  nicht mehr (vorhanden/) aktiv (disabled) ?

Gruß

Thomas

kptkip

ZitatIst eventuell das AT, welches die Daten anfordert,  nicht mehr (vorhanden/) aktiv (disabled) ?

Ich hab kein AT für den ebusd am Laufen. Es gibt nur das per autocreate erstellte MQTT2-Deivce. Sonz nix.
FHEM Revision: 22312 auf RasPI3B+,1xNeumannCUL,HMLAN,1xRasPi3B+,2xRasPI ZERO W
CUL_HM:HM-Sec-SCo, HM-CC-RT-DN
Fritz: Fritz!Box 6590C,DECT301,DECT200
Shelly:Shelly1,Shelly2, ShellyBulb Xiaomi: Schalter, Fensterkontakte HUE: ConbeeII
Tasmota:SonoffBridge, Stecker

TomLee

ZitatDie hatte ich bis vorgestern noch empfangen.

Bezweifle ich.

Mein Vorschlag die Daten anzufordern wäre alternativ zum AT periodicCmd zu verwenden.

Am Beispiel der Heizkurve ergänzt du das Attribut jsonMap um Hc1HeatCurve_0_name:0 Hc1HeatCurve_0_value:Hc1HeatCurve
Das Attribut getList um  Hc1HeatCurve:noArg Hc1HeatCurve ebusd/700/Hc1HeatCurve/get
Und das Attribut periodicCmd bspw. um Hc1HeatCurve:10
Damit sollte der Wert für die Heizkurve alle 10 Minuten angefordert werden und zusätzlich steht im Device ein getter zur Verfügung um den Wert aus dem Device jederzeit manuell anzufordern.

Gruß

Thomas

kptkip

ZitatBezweifle ich.
Ich nicht.

Der Vorschlag hat nichts gebracht - trotzdem danke.

Habs aber jetzt selbst hinbekommen. Das Attribut readingList sieht jetzt so aus:
ebusd/bai/Status01:.* { json2nameValue($EVENT, 'Status01_', $JSONMAP) }
ebusd/bai/Status02:.* { json2nameValue($EVENT, 'Status02_', $JSONMAP) }
ebusd/bai/DateTime:.* { json2nameValue($EVENT, 'DateTime_', $JSONMAP) }
ebusd/430/Hc1HeatCurve:.* { json2nameValue($EVENT, 'Hc1HeatCurve430_', $JSONMAP) }
ebusd/bai/WaterPressure:.* { json2nameValue($EVENT, 'WaterPressure_', $JSONMAP) }
ebusd/bai/Flame:.*  { json2nameValue($EVENT, 'Flame_', $JSONMAP) }
ebusd/global/version:.* version
ebusd/global/running:.* running
ebusd/global/signal:.* signal
ebusd/global/uptime:.* uptime
ebusd/global/updatecheck:.* updatecheck


Damit kommen die Werte jetzt - auch egal, ob sich die Instanz vom ebusd anders benamt.

Gruß
Alex
FHEM Revision: 22312 auf RasPI3B+,1xNeumannCUL,HMLAN,1xRasPi3B+,2xRasPI ZERO W
CUL_HM:HM-Sec-SCo, HM-CC-RT-DN
Fritz: Fritz!Box 6590C,DECT301,DECT200
Shelly:Shelly1,Shelly2, ShellyBulb Xiaomi: Schalter, Fensterkontakte HUE: ConbeeII
Tasmota:SonoffBridge, Stecker

TomLee

Ist schon länger her das ich mich mit dem ebusd beschäftigt habe.

Nutze noch "ebusd 3.3.v3.3", mag sein das sich mit "ebusd 3.4.v3.3-51-g57eae05" etwas geändert hat.

Wenn ich mit einem set am Device die Heizkurve ändere dann kommt auch bei mir eine Rückmeldung, wird aber am Regler selbst die Heizkurve geändert bekomme ich keine.

Wie verhält es sich denn bei dir, ohne AT/periodicCmd ?

kptkip

Hm, gute Frage.

Das hab ich noch garnicht probiert. Ich spiel das mal durch und geb Dir Rückmeldung.
FHEM Revision: 22312 auf RasPI3B+,1xNeumannCUL,HMLAN,1xRasPi3B+,2xRasPI ZERO W
CUL_HM:HM-Sec-SCo, HM-CC-RT-DN
Fritz: Fritz!Box 6590C,DECT301,DECT200
Shelly:Shelly1,Shelly2, ShellyBulb Xiaomi: Schalter, Fensterkontakte HUE: ConbeeII
Tasmota:SonoffBridge, Stecker