Autor Thema: ebus Weishaupt MQTT im Zusammenspiel  (Gelesen 4048 mal)

Offline rob

  • Full Member
  • ***
  • Beiträge: 368
ebus Weishaupt MQTT im Zusammenspiel
« am: 13 Juli 2021, 17:33:38 »
Hallo zusammen.

Hier möchte ich im Weishaupt-spezifischen Dschungel etwas lichten und ein paar Lianen abschlagen ;)

Startpunkte:

Datenkette:

Weishaupt Gastherme WTC-15AebuseBUS Adapter 3.0 ETHERNET (W5500)USR-ES1: Lanebus Dockercontainer john30/ebusd:v21.2MQTTFHEM: myMQTT_Server (MQTT2_SERVER)FHEM: MyEbus_MQTT (MQTT2_DEVICE - splitter)
FHEM: MQTT2_ebusd_21.2_1 (MQTT2_DEVICE 1)
FHEM: MQTT2_ebusd_sc (MQTT2_DEVICE 2)

Zum Nachvollziehen, was habe ich an Schritten durchgeführt:
(Hardware-Krams außen vor, ist unter 1. bestens behandelt)
  • autocreate im MQTT2_Server deaktiviert
attr myMQTT_Server autocreate no
  • MQTT2_Device neu angelegt
define MyEbus_MQTT MQTT2_DEVICE ebusd
  • ebus splitter Template angewandt
set MyEbus_MQTT attrTemplate eBus_daemon_splitter
  • autocreate im MQTT2_Server aktiviert
attr myMQTT_Server autocreate complex
  • J0EK3Rs Repo geladen
git clone https://github.com/J0EK3R/ebusd-configuration-weishaupt.git /home/dietpi/ebus/weishaupt/
  • aus john30s Repo die broadcast.csv und memory.csv geladen und im selben Pfad abgelegt (keine Ahnung, ob es das braucht - wurde aber von ebusd geladen)
  • docker gestartet (für Raspi, latest klappt nur für amd64, da latest aktuell kein multiarch)
docker run -d \
       --name=ebus \
       --restart=always \
       -v /etc/localtime:/etc/localtime:ro \
       -v /home/dietpi/ebus/weishaupt/:/etc/ebusd \
       -p 8888 \
john30/ebusd:v21.2 -f --scanconfig -d enh:192.168.0.188:9999 --latency=80 --accesslevel=* --address=ff --mqttport=1883 --mqttjson --mqtthost=192.168.0.11 --mqtttopic=ebusd/%circuit/%name --mqttchanges --configpath=/etc/ebusd

    Die RAW-Definitionen in FHEM:
    Splitter - MyEbus_MQTT
    defmod MyEbus_MQTT MQTT2_DEVICE ebusd
    attr MyEbus_MQTT IODev myMQTT_Server
    attr MyEbus_MQTT autocreate 1
    attr MyEbus_MQTT 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|solar|ui|uih|v\d\d|v81.\d|vd\d|vl\d|vr_\d\d|zeo)/.*:.* "$1_$2"\
    (ebus..*?)/(global|broadcast|general|scan([^/]*))/.*:.* "$1"
    attr MyEbus_MQTT comment NOTE: additional templates and code have been downloaded from svn (contrib).
    attr MyEbus_MQTT devStateIcon 1.true:it_net 1.false:it_net@red  2.true:lan_rs485 2.false:lan_rs485@red
    attr MyEbus_MQTT event-min-interval 120
    attr MyEbus_MQTT event-on-change-reading .*
    attr MyEbus_MQTT group Gastherme
    attr MyEbus_MQTT icon sani_boiler_temp
    attr MyEbus_MQTT model eBus_daemon_splitter
    attr MyEbus_MQTT readingList ebusd/global/version:.* version\
    ebusd/global/running:.* running\
    ebusd/global/scan:.* scan\
    ebusd/global/uptime:.* uptime\
    ebusd/global/signal:.* signal\
    ebusd/scan\x2e35/:.* { json2nameValue($EVENT, 'scan.35_', $JSONMAP) }\
    ebusd/scan\x2ef6/:.* { json2nameValue($EVENT, 'scan.f6_', $JSONMAP) }\
    ebusd/global/updatecheck:.* updatecheck\
    ebusd/scan\x2e08/:.* { json2nameValue($EVENT, 'scan.08_', $JSONMAP) }
    attr MyEbus_MQTT room 12_Heizraum,MQTT2_DEVICE
    attr MyEbus_MQTT setList getKnown:noArg ebusd/list onlyknown\
      getAll:noArg ebusd/list
    attr MyEbus_MQTT stateFormat Status: \
    1:running\
    Signal: \
    2:signal\
    <br>Uptime: formatedUptime
    attr MyEbus_MQTT 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}
    attr MyEbus_MQTT verbose 0

    setstate MyEbus_MQTT Status: \
    1:true\
    Signal: \
    2:true\
    <br>Uptime: 0 001 02:16
    setstate MyEbus_MQTT 2021-07-12 14:37:43 associatedWith MyEbus_MQTT
    setstate MyEbus_MQTT 2021-07-12 14:32:29 attrTemplateVersion 20200824
    setstate MyEbus_MQTT 2021-07-13 16:50:36 formatedUptime 0 001 02:16
    setstate MyEbus_MQTT 2021-07-12 14:34:16 running true
    setstate MyEbus_MQTT 2021-07-12 14:37:45 scan "finished"
    setstate MyEbus_MQTT 2021-07-12 14:34:32 signal true
    setstate MyEbus_MQTT 2021-07-12 14:32:29 state getKnown
    setstate MyEbus_MQTT 2021-07-12 14:36:53 updatecheck "OK"
    setstate MyEbus_MQTT 2021-07-13 16:50:36 uptime 94580
    setstate MyEbus_MQTT 2021-07-12 14:34:16 version "ebusd 21.2.v21.2"

    Device 1 - MQTT2_ebusd_21.2_1
    defmod MQTT2_ebusd_21.2_1 MQTT2_DEVICE ebusd_21.2_1
    attr MQTT2_ebusd_21.2_1 event-min-interval 120
    attr MQTT2_ebusd_21.2_1 event-on-change-reading .*
    attr MQTT2_ebusd_21.2_1 group Gastherme
    attr MQTT2_ebusd_21.2_1 readingList ebusd_21.2_1:ebusd/hc1/Set:.* { json2nameValue($EVENT, 'Set_', $JSONMAP) }
    attr MQTT2_ebusd_21.2_1 room 12_Heizraum,MQTT2_DEVICE

    setstate MQTT2_ebusd_21.2_1 2021-07-12 14:34:50 IODev myMQTT_Server
    setstate MQTT2_ebusd_21.2_1 2021-07-13 12:57:49 Set_Action_value stopconsumer
    setstate MQTT2_ebusd_21.2_1 2021-07-13 12:57:49 Set_DHWSetTemp_value 48.0
    setstate MQTT2_ebusd_21.2_1 2021-07-13 12:57:49 Set_SetTemp_value 5.00
    setstate MQTT2_ebusd_21.2_1 2021-07-13 12:57:49 Set_Status_value hotwater
    setstate MQTT2_ebusd_21.2_1 2021-07-12 14:35:13 subscriptions ebusd/#

    Device 2 - MQTT2_ebusd_sc
    defmod MQTT2_ebusd_sc MQTT2_DEVICE ebusd_sc
    attr MQTT2_ebusd_sc event-min-interval 120
    attr MQTT2_ebusd_sc event-on-change-reading .*
    attr MQTT2_ebusd_sc group Gastherme
    attr MQTT2_ebusd_sc readingList ebusd/sc/Act:.* { json2nameValue($EVENT, 'Act_', $JSONMAP) }
    attr MQTT2_ebusd_sc room 12_Heizraum,MQTT2_DEVICE

    setstate MQTT2_ebusd_sc 2021-07-13 16:54:42 Act_DHWTemp_value 48.0
    setstate MQTT2_ebusd_sc 2021-07-13 16:54:42 Act_Error_value 0
    setstate MQTT2_ebusd_sc 2021-07-13 16:54:42 Act_ExternalTemp_value 15
    setstate MQTT2_ebusd_sc 2021-07-13 16:54:42 Act_Flame_value 0
    setstate MQTT2_ebusd_sc 2021-07-13 16:54:42 Act_GasValve1_value 0
    setstate MQTT2_ebusd_sc 2021-07-13 16:54:42 Act_GasValve2_value 0
    setstate MQTT2_ebusd_sc 2021-07-13 16:54:42 Act_Load_value 0
    setstate MQTT2_ebusd_sc 2021-07-13 16:54:42 Act_Operatingphase_value BrennerAus
    setstate MQTT2_ebusd_sc 2021-07-13 16:54:42 Act_Pump_value 0
    setstate MQTT2_ebusd_sc 2021-07-13 16:54:42 Act_SettingUV_value Heating
    setstate MQTT2_ebusd_sc 2021-07-13 16:54:42 Act_SoWi_value Summer
    setstate MQTT2_ebusd_sc 2021-07-13 16:54:42 Act_Status1_value 1
    setstate MQTT2_ebusd_sc 2021-07-13 16:54:42 Act_SupplySetTemp_value 8
    setstate MQTT2_ebusd_sc 2021-07-13 16:54:42 Act_SupplyTemp_value 39.0
    setstate MQTT2_ebusd_sc 2021-07-13 16:54:42 Act_TrendTemp_value 19.055
    setstate MQTT2_ebusd_sc 2021-07-13 16:54:42 Act_Ukn2_1_value 1
    setstate MQTT2_ebusd_sc 2021-07-13 16:54:42 Act_Ukn2_2_value 1
    setstate MQTT2_ebusd_sc 2021-07-13 16:54:42 Act_Ukn2_3_value 1
    setstate MQTT2_ebusd_sc 2021-07-13 16:54:42 Act_Ukn3_1_value 0
    setstate MQTT2_ebusd_sc 2021-07-13 16:54:42 Act_Ukn3_3_value 0
    setstate MQTT2_ebusd_sc 2021-07-13 16:54:42 Act_Ukn3_4_value 0
    setstate MQTT2_ebusd_sc 2021-07-13 16:54:42 Act_Ukn3_5_value 0
    setstate MQTT2_ebusd_sc 2021-07-13 16:54:42 Act_Ukn3_6_value 0
    setstate MQTT2_ebusd_sc 2021-07-13 16:54:42 Act_Ukn3_7_value 0
    setstate MQTT2_ebusd_sc 2021-07-13 16:54:42 Act_UknTemp_value 0.0
    setstate MQTT2_ebusd_sc 2021-07-12 14:35:13 IODev myMQTT_Server
    setstate MQTT2_ebusd_sc 2021-07-12 14:35:13 associatedWith MyEbus_MQTT

    Wie ich an den Payload komme, weiß ich nicht so recht. Zumindest stehen die Readings oben dabei. In den Devices "MQTT2_ebusd_21.2_1" und "MQTT2_ebusd_sc" habe ich eine Auswahl an ebus-Templates ➜ rein namentlich will das aber noch nicht passen bzw. ich weiß ich nicht, welches ich anwenden soll.

    Jetzt geht es darum, passende Templates zu finden oder angepasste/ andere Templates zu erfinden, die auch für Weishaupt simpel anwendbar sind.
    Wer schon Visulalisierungen usw. für seine Weishaupt hat, kann diese hier gerne vorstellen. Vielleicht ließe sich dies zum Template machen?

    Vorab schon einmal vielen Dank für Input und Unterstützung.

    Viele Grüße
    rob
    fhem@Raspi3B mit DietPi auf USB-SSD am aktiven Hub | Z-Wave Stick Aeotec | Zigbee Stick Conbee2 | nanoJeeLink | SIGNALduino@433 + @868 MHz | Denkovi USB-OW-Busmaster | config. Firmata@Arduino | EspEasy@WemosD1;Sonoff Basic  | MySensors@Arduino

    Offline rob

    • Full Member
    • ***
    • Beiträge: 368
    Antw:ebus Weishaupt MQTT im Zusammenspiel
    « Antwort #1 am: 14 Juli 2021, 07:40:20 »
    ...damit kein Missverständnis entsteht: Ich warte nicht darauf, dass mir jmd. tolle Sachen einflüstert, sondern wurschtle und teste meinerseits anhand der vorhandenen Templates dran rum. Wird aber ein wenig dauern, bis ich hier was posten kann.

    Aktuell steht die Therme eh auf Sommerzeit, sodass da nicht allzuviel los ist an Readings. Ich denk mal dies ist der Grund... werde zum Testen auf Winterzeit stellen - mal schauen.

    VG
    rob

    fhem@Raspi3B mit DietPi auf USB-SSD am aktiven Hub | Z-Wave Stick Aeotec | Zigbee Stick Conbee2 | nanoJeeLink | SIGNALduino@433 + @868 MHz | Denkovi USB-OW-Busmaster | config. Firmata@Arduino | EspEasy@WemosD1;Sonoff Basic  | MySensors@Arduino

    Offline Beta-User

    • Developer
    • Hero Member
    • ****
    • Beiträge: 15700
    Antw:ebus Weishaupt MQTT im Zusammenspiel
    « Antwort #2 am: 14 Juli 2021, 08:12:54 »
    Dann mal Willkommen!

    [@Rudi: da scheint ein generelles (Codierungs-) Problem drin zu sein, s.u.]

    Vielleicht vorab ein paar Anmerkungen bzgl. "autocreate":
    - Kann man auf dem default (M2S - auch ohne Attribut: simple) lassen. Dann wird auch das "Zentraldevice" von autocreate erstellt, wenn der Dienst gestartet wird, weiter passiert da erst mal nichts.
    - auf "complex" umzustellen war hier hilfreich, v.a. bei den Geräten, die mehrere Topics abonnieren, sieht man dann, welches Reading auf welchem Weg erzeugt wurde. Später werden wir die Präfixe aber meistens löschen (=> bitte erst mal nicht mit den jetzigen Namen zum Loggen etc. verwenden! die Reading-Namen werden sich voraussichtlich ändern!)



    Die Payloads kann ich mir nun schon in etwa vorstellen, aber trotzdem kurz die Antwort darauf, wie man da drankommen kann:
    - Meine eigene bevorzugte Methode ist, mit mosquittos_sub (aus dem Paket mosquitto-clients) schlicht die Topics (bzw. Topic-Strukturen) zu abonnieren. Installation ginge auch auf dem FHEM-Server(-Pi), dazu ein eigenes ssh-Terminal. Andere bevorzugen MQTT.fx, es geht prinzipiell auch mit irgendeinem beliebigen anderen Client.
    - Man kann rawEvents am IO (hier myMQTT_Server) aktivieren (regex ggf. so anpassen, dass man nur das sieht, was einen interessiert, sonst ".*"), und dann im Event-Monitor die Events auf den Server beschränken;
    - man kann auch"Klartextreadings" erstellen, indem man die readingList-Zeilen an den M2D doppelt und einen passenden Namen vergibt ("json_<Reading>").

    Hier würde ich für eine externe Lösung plädieren, wir scheinen ein UTF-Codierungsproblem zu haben, und es würde mich interessieren, ob das schon auf der eBus-Seite angelegt ist, oder erst in FHEM (bei der bridgeRegexp) entsteht...



    @Rudi, falls du hier mitliest: diese "scan\x2e.*"-Zweige sind doch ein UTF-Problem, oder täuscht mich das?
    @rob: Ist dein FHEM ebenfalls "verdockert" oder anders gesagt: kannst du ein paar Infos zu deinem FHEM liefern? (Generell gehe ich davon aus, dass du up-to-date bist!)

    Da wir bei dem Thema sind:
    ebusd/scan\x2e35/:.* { json2nameValue($EVENT, 'scan.35_', $JSONMAP) }\
    ebusd/scan\x2ef6/:.* { json2nameValue($EVENT, 'scan.f6_', $JSONMAP) }\
    ebusd/scan\x2e08/:.* { json2nameValue($EVENT, 'scan.08_', $JSONMAP) }
    Diese Zweige scheinen keine Readings  erzeugt zu haben, was sehr seltsam ist, weil FHEM erkannt hat, dass JSON-Payloads kommen...? Kann man das Provozieren, dass wieder ein scan ausgelöst wird? Wenn ja, sollte der möglichst "generisch" sein, also nicht nur eine einzelne Adresse manuell anschubsen).

    Falls wir feststellen, dass darüber gar keine für FHEM relevanten Infos kommen, sollten wir versuchen, diese Topics direkt auszuknipsen...


    Noch eine generelle Anmerkung bzw. Frage - wo kommen diese Attribute her:
    attr <device> event-min-interval 120
    attr <device> event-on-change-reading .*
    Bitte in der "Findungsphase" keine Attribute setzen, die die Ergebnisse verfälschen können! Es geht erst mal darum rauszufinden, was wann warum wie (automatisch) kommt, und welche pull-Anweisungen wir ggf. dann von FHEM aus starten müssen...

    Jetzt zu den einzelnen Devices:
    Zitat
    Device 1 - MQTT2_ebusd_21.2_1
    defmod MQTT2_ebusd_21.2_1 MQTT2_DEVICE ebusd_21.2_1
    attr MQTT2_ebusd_21.2_1 readingList ebusd_21.2_1:ebusd/hc1/Set:.* { json2nameValue($EVENT, 'Set_', $JSONMAP) }
    Da würde mich interessieren, wo das Device überhaupt herkommt... Die CID sieht irgendwie seltsam aus, es gibt gewisse Überschneidungen mit der Version, aber wie die da hinkommt?

    Wie dem auch sei: Wenn ich ein "Set" (oä.) im Topic finde, bin ich erst mal "alarmiert", weil das in der Regel Anweisungen _an_ das Gerät sind, die man in FHEM nicht haben will (sondern erst die Reaktion der Hardware). Frage: hast du da von anderer Seite her was gepublisht?

    Zitat
    Device 2 - MQTT2_ebusd_sc
    Das scheint die eigentliche (Gas-) Therme zu sein, das Device an sich sieht schon mal ganz ok aus, du kannst m.E. direkt das "Act_" als Prefix aus j2nv() nehmen, dann sehen die "Roh-Readings" schon besser aus:
    attr MQTT2_ebusd_sc readingList ebusd/sc/Act:.* { json2nameValue($EVENT, '', $JSONMAP) }
    Die "Act_.*"-Readings kannst du dann löschen und die sich dann ergebenden Readings  mit dem jsonMap-Attribut in was umbenennen, das dir sinnvoll erscheint. Dabei würde ich dringend empfehlen, "internationalisierte" Reading-Namen zu verwenden, also z.B. "temperature" statt "Temperatur".

    Die "Ukn.*"-Readings dürften Hausaufgaben auf der csv-Seite sein. Vermutlich sind Werte über den Bus verfügbar, die nicht zugeordnet sind.

    Als nächstes wären dann schon setList und getList _an diesem Gerät_ dran. Ich habe jetzt nicht in die vorhandenen templates geschaut, aber ggf. könnte es da bei den "bai"-templates schon was geben, das in die richtige Richtung geht...

    ...damit kein Missverständnis entsteht: Ich warte nicht darauf, dass [...]
    ...paßt schon! War grade am Tippen.

    Zitat
    Aktuell steht die Therme eh auf Sommerzeit, sodass da nicht allzuviel los ist an Readings. Ich denk mal dies ist der Grund...
    Vermutlich ist nicht das der Haupt-Grund, sondern man bekommt afaik beim eBus alle Infos nur "auf Anforderung". Es ist dazu ein "at" im Wiki beschrieben, mein Vorschlag wäre, das durch periodicCmd-Attribute an der jeweiligen Baugruppe zu ersetzen.

    Soviel mal für's erste, CU!
    Server: HP-T620@Debian 10, 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:MySensors, Weekday-&RandomTimer, Twilight,  AttrTemplate {u.a. mqtt2, mysensors, zwave}

    Offline rob

    • Full Member
    • ***
    • Beiträge: 368
    Antw:ebus Weishaupt MQTT im Zusammenspiel
    « Antwort #3 am: 14 Juli 2021, 10:01:52 »
    Vielleicht vorab ein paar Anmerkungen bzgl. "autocreate":
    Alles gemäß WIKI durchgeführt https://wiki.fhem.de/wiki/EBUS-MQTT2#Vorbereitung_und_Definition_in_FHEM. Das Ergebnis daraus sehen wir unverändert - abgesehen von eocr und room :)

    - Meine eigene bevorzugte Methode ist, mit mosquittos_sub
    ...
    Hier würde ich für eine externe Lösung plädieren...
    Hab ich sogar bereits verfügbar ➜ auf meinen OpenWRT-Geräten. Nehm ich doch glatt das. Danke Dir.

    @rob: Ist dein FHEM ebenfalls "verdockert" oder anders gesagt: kannst du ein paar Infos zu deinem FHEM liefern? (Generell gehe ich davon aus, dass du up-to-date bist!)
    Gerne:
    Host: Raspi3 mit Dietpi (Debian) ➜ up to date
    FHEM: direkt auf dem Host installiert ➜ up to date
    MQTT: weitere Clients sind aktiv, insbesondere die YiCAM ist recht gesprächig (motion events)
    ebusd: verdockert

    Aufgrund der Datenkette scheint es imho einige Stelle zu geben, wo ich einen Fehler gemacht haben kann. Ich könnte sehr einfach mein Testsystem starten: clean FHEM in Docker und quasi jungfräulich alles step by step dort anlegen und prüfen. Dann wären Querolanten á la YiCAM außen vor. Würde das helfen?

    Wie dem auch sei: Wenn ich ein "Set" (oä.) im Topic finde, bin ich erst mal "alarmiert", weil das in der Regel Anweisungen _an_ das Gerät sind, die man in FHEM nicht haben will (sondern erst die Reaktion der Hardware). Frage: hast du da von anderer Seite her was gepublisht?
    Nein, ich habe nichts gepublisht - Device angelegt wie im WIKI und eocr+room gesetzt. Gefällt mir garnicht. Ich bin auch alarmiert. Denn genau das ist es, was ich auf keinen Fall möchte. Ich möchte nur mitlesen am ebus und nix schreiben. Erst recht solange ich garnicht weiß, was es tut (bzgl. CSV).

    Die "Ukn.*"-Readings dürften Hausaufgaben auf der csv-Seite sein. Vermutlich sind Werte über den Bus verfügbar, die nicht zugeordnet sind.
    Ja, J0EK3R schreibt auch, dass er die CSV nicht mehr pflegen kann und er Bedarf sieht. Das würde ich gerne top down halten und angehen, sobald ich MQTT-FHEM-seitig mehr Land sehe :)

    ...man bekommt afaik beim eBus alle Infos nur "auf Anforderung". Es ist dazu ein "at" im Wiki beschrieben, mein Vorschlag wäre, das durch periodicCmd-Attribute an der jeweiligen Baugruppe zu ersetzen.
    Ja, hab ich auch so gelesen/ verstanden. Mein Problem ist nur: Woher kenne ich die Topics um sie via get zu holen, wenn sie bislang nirgends published wurden? Würde ich aber zunächst hinten an stellen das rauszufinden. Das Attribut periodicCMD finde ich schon absolut klasse.

    Die Template-Geschichte scheint mir auch erst einmal zweitrangig. Wichtiger ist mir zu verstehen, woher das "Set" kommt. Das lässt mich zweifeln, ob mein Bastelprojekt ebus richtig ist. Mag keine 5.000 Lehrgeld zahlen.

    OK, bin jetzt am Loggen und starte Docker neu, das provoziert ggf. weitere Meldungen.

    Viele Grüße
    rob
    fhem@Raspi3B mit DietPi auf USB-SSD am aktiven Hub | Z-Wave Stick Aeotec | Zigbee Stick Conbee2 | nanoJeeLink | SIGNALduino@433 + @868 MHz | Denkovi USB-OW-Busmaster | config. Firmata@Arduino | EspEasy@WemosD1;Sonoff Basic  | MySensors@Arduino

    Offline rudolfkoenig

    • Administrator
    • Hero Member
    • *****
    • Beiträge: 24495
    Antw:ebus Weishaupt MQTT im Zusammenspiel
    « Antwort #4 am: 14 Juli 2021, 10:23:40 »
    Zitat
    @Rudi, falls du hier mitliest: diese "scan\x2e.*"-Zweige sind doch ein UTF-Problem, oder täuscht mich das?
    Ich hoffe ja, sowohl was UTF, wie auch was Problem betrifft.
    scan\x2e35 entspricht scan.35 (\x2e ist Punkt), und es wurde umgewandelt, damit beim Regexp keine Ueberraschungen gibt.

    Offline Beta-User

    • Developer
    • Hero Member
    • ****
    • Beiträge: 15700
    Antw:ebus Weishaupt MQTT im Zusammenspiel
    « Antwort #5 am: 14 Juli 2021, 11:29:53 »
    Ich hoffe ja, sowohl was UTF, wie auch was Problem betrifft.
    scan\x2e35 entspricht scan.35 (\x2e ist Punkt), und es wurde umgewandelt, damit beim Regexp keine Ueberraschungen gibt.
    (Ohne jetzt im Code geschaut zu haben), gehe ich davon aus, dass das "immer" so gemacht wird und daher unproblematisch ist, ok.
    (OT-Anmerkung: Ich sehe zwar das theoretische Problem speziell mit dem Punkt, glaube allerdings nicht, dass der auch proaktisch ein Problem darstellt).

    [OT2 @Rudi]
    Wir werden sowieso jsonMap brauchen, aber dieses "permanente .*_value"-Namensgebung (die aus der inneren Struktur des JSON kommt) ist eigentlich unnötig. Vielleicht hast du irgendeine Idee, wie man das auf elegantem Weg gleich vor/bei j2nv() "umbiegen" könnte?
    [/OT2]

    Komisch ist und bleibt, dass da keine Readings zu sehen sind; scheint so, dass der "JSON" schlicht leer ist, oder?

    Alles gemäß WIKI durchgeführt https://wiki.fhem.de/wiki/EBUS-MQTT2#Vorbereitung_und_Definition_in_FHEM. Das Ergebnis daraus sehen wir unverändert - abgesehen von eocr und room :)
    ...deine Frage war ja auch, ob man was im Wiki ändern sollte...
    MAn. sollte man, aber möglichst in enger Abstimmung mit @Reinhart (=> gesonderter Thread im Wiki-Bereich mit Hinweis an ihn an geeigneter Stelle?). Ist zwar u.A. auch an dem Punkt nicht "zwingend" aber eben unnötig kompliziert. Der Spur nach wäre meine persönliche Meinung: autocreate auf "default" (=simple) lassen, und (auch für eBus!) nur ändern, wenn man es mit "speziellen" bzw. noch unbekannten Themen zu tun hat. Zum Hintergrund: Argument 2 ("prefix") hilft, um rauszufinden, wo was herkommt, und kann (bei Bedarf!) dazu genutzt werden, ansonsten (vermeintlich) identische Informationen auseinanderzuhalten, die aus verschiedenen Quellen kommt. Argument 3 ($JSONMAP) macht nur Sinn, wenn man auch ein entsprechende Mapping vornimmt => entweder attrTemplate oder der User muss sowieso aktiv werden...

    Zitat
    [...] Würde das helfen?
    Betr. der Kodierungsfrage ist es geklärt, und ansonsten sehe ich bisher keine Konflikte. Das darf also gerne so bleiben - die "praxisnahe Mischung" sorgt ggf. dafür, dass Schwachpunkte eher auffallen ;) .

    Bzgl. dem "Set": Sollte man erst mal nicht dramatisieren, ist nur sehr komisch, auch weil ich die CID nicht so recht nachvollziehen kann. Es scheint eine "Pseudo-CID" (aus bridgeRegexp) zu sein, und bei der Gelegenheit muss ich mich auch nochmal ansehen, ob da Klarstellungsbedarf besteht hinsichtlich der Wechselwirkung aus einer ggf. gesetzten bridgeRegexp, wenn M2C im Spiel ist... (nicht verwirren lassen, ist mehr für mich selbst).



    Zitat
    Ja, J0EK3R schreibt auch, dass er die CSV nicht mehr pflegen kann und er Bedarf sieht. Das würde ich gerne top down halten und angehen, sobald ich MQTT-FHEM-seitig mehr Land sehe :)
    Das eilt (FHEM-seitig) nicht, FHEM ist es "im Prinzip egal", wie die Readings heißen, und jedenfalls solange sie nicht identisch sind, ist es auch für die hier relevante Verarbeitungskette egal, ob "knwon" oder "Uknx"...

    Zitat
    Woher kenne ich die Topics um sie via get zu holen [...]
    Generell: Häufig über die "subscriptions". Hier aber schwierig, weil der ebus-daemon einfach alles haben will:
    Zitat
    setstate MQTT2_ebusd_21.2_1 2021-07-12 14:35:13 subscriptions ebusd/#
    Konkret (aber aus dem Kopf): Die Abfragepfade kann man aus Readings-Topics ableiten, oder? (Bitte mal die "at"-Pfade und die readingList von den vorhandenen attrTemplate vergleichen). Es müßte dazu auch Info in den älteren Threads zu finden sein; es gibt afaik auch die Option, alle vorhandenen Register auszulesen, das ist nur nicht (dauerhaft) zu empfehlen, weil der Bus dadurch stark belastet wird.
    Dazu bitte ggf. einfach auch nochmal bei den ebus-Experten nachfragen, wie man das am besten macht.

    "Ernsthafte Verletzungsgefahr" besteht aber mAn. bis dato nicht.
    Server: HP-T620@Debian 10, 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:MySensors, Weekday-&RandomTimer, Twilight,  AttrTemplate {u.a. mqtt2, mysensors, zwave}

    Offline rob

    • Full Member
    • ***
    • Beiträge: 368
    Antw:ebus Weishaupt MQTT im Zusammenspiel
    « Antwort #6 am: 14 Juli 2021, 11:54:49 »
    OK, Alarm beendet. Ich bin da etwas nervös - dafür kann natürlich keiner was, der Ball liegt bei mir  ::) :)
    Das "Set_" scheint also nur ein Prefix zu sein analog dem "ACT_". Ich hatte das gedanklich mit einem MQTT set im publish verwechselt (sowas wie "set myMQTT_Server publish ebus/blabla/set")

    ...mal die "at"-Pfade und die readingList von den vorhandenen attrTemplate vergleichen ...
    Dazu bitte ggf. einfach auch nochmal bei den ebus-Experten nachfragen, wie man das am besten macht.
    Genau da liegt der Hase im Pfeffer: alles was ich bisher fand ist auf Vaillant oder Wolf abgestimmt. Weishaupt ist wohl nicht so verbreitet und das heißt alles anders in den Topics. Aber fragen kost nix - mach ich natürlich.

    So, das Log müsste erst mal reichen (hab den Winter kurz vorgezogen). Den Uptime-Krams hab ich rausgeworfen.
    Client mosqsub/16320-OpenWRT sending CONNECT
    Client mosqsub/16320-OpenWRT received CONNACK
    Client mosqsub/16320-OpenWRT sending SUBSCRIBE (Mid: 1, Topic: ebusd/#, QoS: 0)
    Client mosqsub/16320-OpenWRT received SUBACK
    Subscribed (mid: 1): 1
    Client mosqsub/16320-OpenWRT received PUBLISH (d0, q0, r0, m0, 'ebusd/global/signal', ... (4 bytes))
    true
    Client mosqsub/16320-OpenWRT received PUBLISH (d0, q0, r0, m0, 'ebusd/global/version', ... (18 bytes))
    "ebusd 21.2.v21.2"
    Client mosqsub/16320-OpenWRT received PUBLISH (d0, q0, r0, m0, 'ebusd/global/running', ... (4 bytes))
    true
    Client mosqsub/16320-OpenWRT received PUBLISH (d0, q0, r0, m0, 'ebusd/global/updatecheck', ... (4 bytes))
    "OK"
    Client mosqsub/16320-OpenWRT received PUBLISH (d0, q0, r0, m0, 'ebusd/global/scan', ... (10 bytes))
    "finished"

    Client mosqsub/16320-OpenWRT received PUBLISH (d0, q0, r0, m0, 'ebusd/sc/Act', ... (835 bytes))
    {
         "Status1": {"value": 1},
         "Operatingphase": {"value": "BrennerAus"},
         "Ukn2_1": {"value": 1},
         "Ukn2_2": {"value": 1},
         "Ukn2_3": {"value": 1},
         "Flame": {"value": 0},
         "GasValve1": {"value": 0},
         "GasValve2": {"value": 0},
         "Pump": {"value": 0},
         "Error": {"value": 0},
         "Ukn3_1": {"value": 0},
         "SoWi": {"value": "Summer"},
         "Ukn3_3": {"value": 0},
         "Ukn3_4": {"value": 0},
         "Ukn3_5": {"value": 0},
         "Ukn3_6": {"value": 0},
         "Ukn3_7": {"value": 0},
         "SettingUV": {"value": "Heating"},
         "Load": {"value": 0},
         "SupplyTemp": {"value": 44.0},
         "FlueGasTemp": {"value": null},
         "DHWTemp": {"value": 48.0},
         "UknTemp": {"value": 0.0},
         "ExternalTemp": {"value": 17},
         "TrendTemp": {"value": 16.605},
         "SupplySetTemp": {"value": 8}}
    Client mosqsub/16320-OpenWRT received PUBLISH (d0, q0, r0, m0, 'ebusd/sc/Act', ... (835 bytes))
    {
         "Status1": {"value": 1},
         "Operatingphase": {"value": "BrennerAus"},
         "Ukn2_1": {"value": 1},
         "Ukn2_2": {"value": 1},
         "Ukn2_3": {"value": 1},
         "Flame": {"value": 0},
         "GasValve1": {"value": 0},
         "GasValve2": {"value": 0},
         "Pump": {"value": 0},
         "Error": {"value": 0},
         "Ukn3_1": {"value": 0},
         "SoWi": {"value": "Summer"},
         "Ukn3_3": {"value": 0},
         "Ukn3_4": {"value": 0},
         "Ukn3_5": {"value": 0},
         "Ukn3_6": {"value": 0},
         "Ukn3_7": {"value": 0},
         "SettingUV": {"value": "Heating"},
         "Load": {"value": 0},
         "SupplyTemp": {"value": 44.0},
         "FlueGasTemp": {"value": null},
         "DHWTemp": {"value": 48.0},
         "UknTemp": {"value": 0.0},
         "ExternalTemp": {"value": 17},
         "TrendTemp": {"value": 16.617},
         "SupplySetTemp": {"value": 8}}
    Client mosqsub/16320-OpenWRT received PUBLISH (d0, q0, r0, m0, 'ebusd/sc/Act', ... (835 bytes))
    {
         "Status1": {"value": 1},
         "Operatingphase": {"value": "BrennerAus"},
         "Ukn2_1": {"value": 1},
         "Ukn2_2": {"value": 1},
         "Ukn2_3": {"value": 1},
         "Flame": {"value": 0},
         "GasValve1": {"value": 0},
         "GasValve2": {"value": 0},
         "Pump": {"value": 0},
         "Error": {"value": 0},
         "Ukn3_1": {"value": 0},
         "SoWi": {"value": "Summer"},
         "Ukn3_3": {"value": 0},
         "Ukn3_4": {"value": 0},
         "Ukn3_5": {"value": 0},
         "Ukn3_6": {"value": 0},
         "Ukn3_7": {"value": 0},
         "SettingUV": {"value": "Heating"},
         "Load": {"value": 0},
         "SupplyTemp": {"value": 44.0},
         "FlueGasTemp": {"value": null},
         "DHWTemp": {"value": 48.0},
         "UknTemp": {"value": 0.0},
         "ExternalTemp": {"value": 17},
         "TrendTemp": {"value": 16.617},
         "SupplySetTemp": {"value": 8}}
    Client mosqsub/16320-OpenWRT received PUBLISH (d0, q0, r0, m0, 'ebusd/sc/Act', ... (835 bytes))
    {
         "Status1": {"value": 1},
         "Operatingphase": {"value": "BrennerAus"},
         "Ukn2_1": {"value": 1},
         "Ukn2_2": {"value": 1},
         "Ukn2_3": {"value": 1},
         "Flame": {"value": 0},
         "GasValve1": {"value": 0},
         "GasValve2": {"value": 0},
         "Pump": {"value": 0},
         "Error": {"value": 0},
         "Ukn3_1": {"value": 0},
         "SoWi": {"value": "Summer"},
         "Ukn3_3": {"value": 0},
         "Ukn3_4": {"value": 0},
         "Ukn3_5": {"value": 0},
         "Ukn3_6": {"value": 0},
         "Ukn3_7": {"value": 0},
         "SettingUV": {"value": "Heating"},
         "Load": {"value": 0},
         "SupplyTemp": {"value": 44.0},
         "FlueGasTemp": {"value": null},
         "DHWTemp": {"value": 48.0},
         "UknTemp": {"value": 0.0},
         "ExternalTemp": {"value": 17},
         "TrendTemp": {"value": 16.621},
         "SupplySetTemp": {"value": 8}}

    ---docker restartet ----

    Client mosqsub/16320-OpenWRT received PUBLISH (d0, q0, r0, m0, 'ebusd/global/version', ... (18 bytes))
    "ebusd 21.2.v21.2"
    Client mosqsub/16320-OpenWRT received PUBLISH (d0, q0, r0, m0, 'ebusd/global/running', ... (4 bytes))
    true
    Client mosqsub/16320-OpenWRT received PUBLISH (d0, q0, r0, m0, 'ebusd/global/scan', ... (9 bytes))
    "running"
    Client mosqsub/16320-OpenWRT received PUBLISH (d0, q0, r0, m0, 'ebusd/scan.35/', ... (126 bytes))
    {
         "MF": {"value": "Kromschroeder"},
         "ID": {"value": "W "},
         "SW": {"value": "2726"},
         "HW": {"value": null}}
    Client mosqsub/16320-OpenWRT received PUBLISH (d0, q0, r0, m0, 'ebusd/scan.f6/', ... (131 bytes))
    {
         "MF": {"value": "Kromschroeder"},
         "ID": {"value": "WWST?"},
         "SW": {"value": "1200"},
         "HW": {"value": "0302"}}
    Client mosqsub/16320-OpenWRT received PUBLISH (d0, q0, r0, m0, 'ebusd/global/scan', ... (10 bytes))
    "finished"
    Client mosqsub/16320-OpenWRT received PUBLISH (d0, q0, r0, m0, 'ebusd/global/uptime', ... (2 bytes))
    16
    Client mosqsub/16320-OpenWRT received PUBLISH (d0, q0, r0, m0, 'ebusd/global/signal', ... (4 bytes))
    true
    Client mosqsub/16320-OpenWRT received PUBLISH (d0, q0, r0, m0, 'ebusd/global/scan', ... (9 bytes))
    "running"
    Client mosqsub/16320-OpenWRT received PUBLISH (d0, q0, r0, m0, 'ebusd/hc1/Set', ... (259 bytes))
    {
         "Status": {"value": "hotwater"},
         "Action": {"value": "stopconsumer"},
         "SetTemp": {"value": 5.00},
         "SetPressure": {"value": null},
         "OutputDegree": {"value": null},
         "DHWSetTemp": {"value": 48.0},
         "Fueltype": {"value": null}}
    Client mosqsub/16320-OpenWRT received PUBLISH (d0, q0, r0, m0, 'ebusd/global/scan', ... (10 bytes))
    "finished"
    Client mosqsub/16320-OpenWRT received PUBLISH (d0, q0, r0, m0, 'ebusd/global/uptime', ... (2 bytes))
    32
    Client mosqsub/16320-OpenWRT received PUBLISH (d0, q0, r0, m0, 'ebusd/sc/Act', ... (835 bytes))
    {
         "Status1": {"value": 1},
         "Operatingphase": {"value": "BrennerAus"},
         "Ukn2_1": {"value": 1},
         "Ukn2_2": {"value": 1},
         "Ukn2_3": {"value": 1},
         "Flame": {"value": 0},
         "GasValve1": {"value": 0},
         "GasValve2": {"value": 0},
         "Pump": {"value": 0},
         "Error": {"value": 0},
         "Ukn3_1": {"value": 0},
         "SoWi": {"value": "Summer"},
         "Ukn3_3": {"value": 0},
         "Ukn3_4": {"value": 0},
         "Ukn3_5": {"value": 0},
         "Ukn3_6": {"value": 0},
         "Ukn3_7": {"value": 0},
         "SettingUV": {"value": "Heating"},
         "Load": {"value": 0},
         "SupplyTemp": {"value": 44.0},
         "FlueGasTemp": {"value": null},
         "DHWTemp": {"value": 48.0},
         "UknTemp": {"value": 0.0},
         "ExternalTemp": {"value": 17},
         "TrendTemp": {"value": 16.621},
         "SupplySetTemp": {"value": 8}}
    Client mosqsub/16320-OpenWRT received PUBLISH (d0, q0, r0, m0, 'ebusd/global/uptime', ... (2 bytes))
    48
    Client mosqsub/16320-OpenWRT sending PINGREQ
    Client mosqsub/16320-OpenWRT received PINGRESP
    Client mosqsub/16320-OpenWRT received PUBLISH (d0, q0, r0, m0, 'ebusd/sc/Act', ... (835 bytes))
    {
         "Status1": {"value": 1},
         "Operatingphase": {"value": "BrennerAus"},
         "Ukn2_1": {"value": 1},
         "Ukn2_2": {"value": 1},
         "Ukn2_3": {"value": 1},
         "Flame": {"value": 0},
         "GasValve1": {"value": 0},
         "GasValve2": {"value": 0},
         "Pump": {"value": 0},
         "Error": {"value": 0},
         "Ukn3_1": {"value": 0},
         "SoWi": {"value": "Summer"},
         "Ukn3_3": {"value": 0},
         "Ukn3_4": {"value": 0},
         "Ukn3_5": {"value": 0},
         "Ukn3_6": {"value": 0},
         "Ukn3_7": {"value": 0},
         "SettingUV": {"value": "Heating"},
         "Load": {"value": 0},
         "SupplyTemp": {"value": 44.0},
         "FlueGasTemp": {"value": null},
         "DHWTemp": {"value": 48.0},
         "UknTemp": {"value": 0.0},
         "ExternalTemp": {"value": 17},
         "TrendTemp": {"value": 16.625},
         "SupplySetTemp": {"value": 8}}
    Client mosqsub/16320-OpenWRT received PUBLISH (d0, q0, r0, m0, 'ebusd/scan.08/', ... (128 bytes))
    {
         "MF": {"value": "Kromschroeder"},
         "ID": {"value": "W "},
         "SW": {"value": "1200"},
         "HW": {"value": "0302"}}
    Client mosqsub/16320-OpenWRT received PUBLISH (d0, q0, r0, m0, 'ebusd/global/scan', ... (9 bytes))
    "running"
    Client mosqsub/16320-OpenWRT received PUBLISH (d0, q0, r0, m0, 'ebusd/global/uptime', ... (3 bytes))
    208
    Client mosqsub/16320-OpenWRT received PUBLISH (d0, q0, r0, m0, 'ebusd/global/scan', ... (10 bytes))
    "finished"
    Client mosqsub/16320-OpenWRT received PUBLISH (d0, q0, r0, m0, 'ebusd/sc/Act', ... (835 bytes))
    {
         "Status1": {"value": 1},
         "Operatingphase": {"value": "BrennerAus"},
         "Ukn2_1": {"value": 1},
         "Ukn2_2": {"value": 1},
         "Ukn2_3": {"value": 1},
         "Flame": {"value": 0},
         "GasValve1": {"value": 0},
         "GasValve2": {"value": 0},
         "Pump": {"value": 0},
         "Error": {"value": 0},
         "Ukn3_1": {"value": 0},
         "SoWi": {"value": "Summer"},
         "Ukn3_3": {"value": 0},
         "Ukn3_4": {"value": 0},
         "Ukn3_5": {"value": 0},
         "Ukn3_6": {"value": 0},
         "Ukn3_7": {"value": 0},
         "SettingUV": {"value": "Heating"},
         "Load": {"value": 0},
         "SupplyTemp": {"value": 44.0},
         "FlueGasTemp": {"value": null},
         "DHWTemp": {"value": 48.0},
         "UknTemp": {"value": 0.0},
         "ExternalTemp": {"value": 17},
         "TrendTemp": {"value": 16.629},
         "SupplySetTemp": {"value": 8}}
    Client mosqsub/16320-OpenWRT received PUBLISH (d0, q0, r0, m0, 'ebusd/sc/Act', ... (835 bytes))
    {
         "Status1": {"value": 1},
         "Operatingphase": {"value": "BrennerAus"},
         "Ukn2_1": {"value": 1},
         "Ukn2_2": {"value": 1},
         "Ukn2_3": {"value": 1},
         "Flame": {"value": 0},
         "GasValve1": {"value": 0},
         "GasValve2": {"value": 0},
         "Pump": {"value": 0},
         "Error": {"value": 0},
         "Ukn3_1": {"value": 0},
         "SoWi": {"value": "Summer"},
         "Ukn3_3": {"value": 0},
         "Ukn3_4": {"value": 0},
         "Ukn3_5": {"value": 0},
         "Ukn3_6": {"value": 0},
         "Ukn3_7": {"value": 0},
         "SettingUV": {"value": "Heating"},
         "Load": {"value": 0},
         "SupplyTemp": {"value": 44.0},
         "FlueGasTemp": {"value": null},
         "DHWTemp": {"value": 48.0},
         "UknTemp": {"value": 0.0},
         "ExternalTemp": {"value": 17},
         "TrendTemp": {"value": 16.637},
         "SupplySetTemp": {"value": 8}}
    Client mosqsub/16320-OpenWRT received PUBLISH (d0, q0, r0, m0, 'ebusd/sc/Act', ... (835 bytes))
    {
         "Status1": {"value": 1},
         "Operatingphase": {"value": "BrennerAus"},
         "Ukn2_1": {"value": 1},
         "Ukn2_2": {"value": 1},
         "Ukn2_3": {"value": 1},
         "Flame": {"value": 0},
         "GasValve1": {"value": 0},
         "GasValve2": {"value": 0},
         "Pump": {"value": 0},
         "Error": {"value": 0},
         "Ukn3_1": {"value": 0},
         "SoWi": {"value": "Summer"},
         "Ukn3_3": {"value": 0},
         "Ukn3_4": {"value": 0},
         "Ukn3_5": {"value": 0},
         "Ukn3_6": {"value": 0},
         "Ukn3_7": {"value": 0},
         "SettingUV": {"value": "Heating"},
         "Load": {"value": 0},
         "SupplyTemp": {"value": 44.0},
         "FlueGasTemp": {"value": null},
         "DHWTemp": {"value": 48.0},
         "UknTemp": {"value": 0.0},
         "ExternalTemp": {"value": 17},
         "TrendTemp": {"value": 16.641},
         "SupplySetTemp": {"value": 8}}
    Client mosqsub/16320-OpenWRT received PUBLISH (d0, q0, r0, m0, 'ebusd/sc/Act', ... (835 bytes))
    {
         "Status1": {"value": 1},
         "Operatingphase": {"value": "BrennerAus"},
         "Ukn2_1": {"value": 1},
         "Ukn2_2": {"value": 1},
         "Ukn2_3": {"value": 1},
         "Flame": {"value": 0},
         "GasValve1": {"value": 0},
         "GasValve2": {"value": 0},
         "Pump": {"value": 0},
         "Error": {"value": 0},
         "Ukn3_1": {"value": 0},
         "SoWi": {"value": "Summer"},
         "Ukn3_3": {"value": 0},
         "Ukn3_4": {"value": 0},
         "Ukn3_5": {"value": 0},
         "Ukn3_6": {"value": 0},
         "Ukn3_7": {"value": 0},
         "SettingUV": {"value": "Heating"},
         "Load": {"value": 0},
         "SupplyTemp": {"value": 44.0},
         "FlueGasTemp": {"value": null},
         "DHWTemp": {"value": 48.0},
         "UknTemp": {"value": 0.0},
         "ExternalTemp": {"value": 17},
         "TrendTemp": {"value": 16.645},
         "SupplySetTemp": {"value": 8}}
    Client mosqsub/16320-OpenWRT received PUBLISH (d0, q0, r0, m0, 'ebusd/sc/Act', ... (835 bytes))
    {
         "Status1": {"value": 1},
         "Operatingphase": {"value": "BrennerAus"},
         "Ukn2_1": {"value": 1},
         "Ukn2_2": {"value": 1},
         "Ukn2_3": {"value": 1},
         "Flame": {"value": 0},
         "GasValve1": {"value": 0},
         "GasValve2": {"value": 0},
         "Pump": {"value": 0},
         "Error": {"value": 0},
         "Ukn3_1": {"value": 0},
         "SoWi": {"value": "Summer"},
         "Ukn3_3": {"value": 0},
         "Ukn3_4": {"value": 0},
         "Ukn3_5": {"value": 0},
         "Ukn3_6": {"value": 0},
         "Ukn3_7": {"value": 0},
         "SettingUV": {"value": "Heating"},
         "Load": {"value": 0},
         "SupplyTemp": {"value": 44.0},
         "FlueGasTemp": {"value": null},
         "DHWTemp": {"value": 48.0},
         "UknTemp": {"value": 0.0},
         "ExternalTemp": {"value": 17},
         "TrendTemp": {"value": 16.648},
         "SupplySetTemp": {"value": 8}}
    Client mosqsub/16320-OpenWRT received PUBLISH (d0, q0, r0, m0, 'ebusd/sc/Act', ... (835 bytes))
    {
         "Status1": {"value": 1},
         "Operatingphase": {"value": "BrennerAus"},
         "Ukn2_1": {"value": 1},
         "Ukn2_2": {"value": 1},
         "Ukn2_3": {"value": 1},
         "Flame": {"value": 0},
         "GasValve1": {"value": 0},
         "GasValve2": {"value": 0},
         "Pump": {"value": 0},
         "Error": {"value": 0},
         "Ukn3_1": {"value": 0},
         "SoWi": {"value": "Summer"},
         "Ukn3_3": {"value": 0},
         "Ukn3_4": {"value": 0},
         "Ukn3_5": {"value": 0},
         "Ukn3_6": {"value": 0},
         "Ukn3_7": {"value": 0},
         "SettingUV": {"value": "Heating"},
         "Load": {"value": 0},
         "SupplyTemp": {"value": 44.0},
         "FlueGasTemp": {"value": null},
         "DHWTemp": {"value": 48.0},
         "UknTemp": {"value": 0.0},
         "ExternalTemp": {"value": 18},
         "TrendTemp": {"value": 16.648},
         "SupplySetTemp": {"value": 8}}

    Edit: ja, war zu lang. In der Vorschau sah alles gut aus.
    « Letzte Änderung: 14 Juli 2021, 12:40:29 von rob »
    fhem@Raspi3B mit DietPi auf USB-SSD am aktiven Hub | Z-Wave Stick Aeotec | Zigbee Stick Conbee2 | nanoJeeLink | SIGNALduino@433 + @868 MHz | Denkovi USB-OW-Busmaster | config. Firmata@Arduino | EspEasy@WemosD1;Sonoff Basic  | MySensors@Arduino

    Offline Beta-User

    • Developer
    • Hero Member
    • ****
    • Beiträge: 15700
    Antw:ebus Weishaupt MQTT im Zusammenspiel
    « Antwort #7 am: 14 Juli 2021, 12:24:29 »
    (Formatierung ist leider kapput, war wohl zu viel Info => ggf. künftig lieber als txt-Anhang?)

    Was das "Set" angeht: vermutlich ist das so als Topic konfiguriert (indirekt über die csv?), es scheint sich um die aktuellen settings zu handeln. Ich finde das "unglücklich", also falls du die richtige Stelle findest, um das anzupassen, wäre die Frage, ob das geht, ohne Inkompabilitäten heraufzubeschwören?

    Was die "scan"-Sachen angeht, müßten jetzt Werte vorhanden sein, oder?
    Was jeweils gescannt wird, scheint nach diesem Beitrag v.a. davon abzuhängen, welche csv's vorhanden sind?
    Zitat
    alles was ich bisher fand ist auf Vaillant oder Wolf abgestimmt. Weishaupt ist wohl nicht so verbreitet und das heißt alles anders in den Topics.
    Jein... Nach meinem (evtl. falschen!) Verständnis ist es prinzipiell nicht wichtig, welcher Hersteller dahinter steht. ebusd als zentraler Dienst übersetzt das dann jeweils, wird aber seinerseits immer durch dieses Anhängsel "/get" aufgefordert, die am jeweiligen Ort vorhandenen (!) Werte auszuliefern. Welche Topics/Werte vorhanden sind, müßte man eigentlich aus den csv's rekonstruieren können. Und die sind dann auch wieder eigentlich "relativ" standardisiert, was die Struktur an sich angeht - es schreibt nur eben jeder "irgendwas" rein, was er jeweils für sinnvoll erachtet, z.B. Texte wie "hotwaterinheating" oder "BrennerAus"...
    (Das ist ein anderes Thema, aber m.E. wäre es u.A. auch wünschenswert, hier standardisiertere (englische) Werte zu verwenden, ohne allerdings sagen zu können, wie die im Detail aussehen könnten).
    Server: HP-T620@Debian 10, 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:MySensors, Weekday-&RandomTimer, Twilight,  AttrTemplate {u.a. mqtt2, mysensors, zwave}

    Offline rob

    • Full Member
    • ***
    • Beiträge: 368
    Antw:ebus Weishaupt MQTT im Zusammenspiel
    « Antwort #8 am: 14 Juli 2021, 12:59:56 »
    Was die "scan"-Sachen angeht, müßten jetzt Werte vorhanden sein, oder?
    In Fhem sehe ich keine Veränderung. Habe autocreate auf simple und ebus-docker restartet. (oecr habe ich vorsichtshalber raus). Keine neuen Devices, keine neuen Readings.

    list -r .*[E|e]bus.* sagt:
    define FileLog_MQTT2_ebusd_21.2_1 FileLog ./log/MQTT2_ebusd_21.2_1-%Y-%m-%d.log MQTT2_ebusd_21.2_1
    attr FileLog_MQTT2_ebusd_21.2_1 group Gastherme
    attr FileLog_MQTT2_ebusd_21.2_1 logtype text
    attr FileLog_MQTT2_ebusd_21.2_1 room 12_Heizraum,MQTT2_DEVICE

    define FileLog_MQTT2_ebusd_sc FileLog ./log/MQTT2_ebusd_sc-%Y-%m-%d.log MQTT2_ebusd_sc
    attr FileLog_MQTT2_ebusd_sc group Gastherme
    attr FileLog_MQTT2_ebusd_sc logtype text
    attr FileLog_MQTT2_ebusd_sc room 12_Heizraum,MQTT2_DEVICE

    define MQTT2_ebusd_21.2_1 MQTT2_DEVICE ebusd_21.2_1
    attr MQTT2_ebusd_21.2_1 group Gastherme
    attr MQTT2_ebusd_21.2_1 readingList ebusd_21.2_1:ebusd/hc1/Set:.* { json2nameValue($EVENT, 'Set_', $JSONMAP) }
    attr MQTT2_ebusd_21.2_1 room 12_Heizraum,MQTT2_DEVICE

    define MQTT2_ebusd_sc MQTT2_DEVICE ebusd_sc
    attr MQTT2_ebusd_sc group Gastherme
    attr MQTT2_ebusd_sc readingList ebusd/sc/Act:.* { json2nameValue($EVENT, 'Act_', $JSONMAP) }
    attr MQTT2_ebusd_sc room 12_Heizraum,MQTT2_DEVICE

    define MyEbus_MQTT MQTT2_DEVICE ebusd
    attr MyEbus_MQTT IODev myMQTT_Server
    attr MyEbus_MQTT autocreate 1
    attr MyEbus_MQTT 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|solar|ui|uih|v\d\d|v81.\d|vd\d|vl\d|vr_\d\d|zeo)/.*:.* "$1_$2"\
    (ebus..*?)/(global|broadcast|general|scan([^/]*))/.*:.* "$1"
    attr MyEbus_MQTT comment NOTE: additional templates and code have been downloaded from svn (contrib).
    attr MyEbus_MQTT devStateIcon 1.true:it_net 1.false:it_net@red  2.true:lan_rs485 2.false:lan_rs485@red
    attr MyEbus_MQTT group Gastherme
    attr MyEbus_MQTT icon sani_boiler_temp
    attr MyEbus_MQTT model eBus_daemon_splitter
    attr MyEbus_MQTT readingList ebusd/global/version:.* version\
    ebusd/global/running:.* running\
    ebusd/global/scan:.* scan\
    ebusd/global/uptime:.* uptime\
    ebusd/global/signal:.* signal\
    ebusd/scan\x2e35/:.* { json2nameValue($EVENT, 'scan.35_', $JSONMAP) }\
    ebusd/scan\x2ef6/:.* { json2nameValue($EVENT, 'scan.f6_', $JSONMAP) }\
    ebusd/global/updatecheck:.* updatecheck\
    ebusd/scan\x2e08/:.* { json2nameValue($EVENT, 'scan.08_', $JSONMAP) }
    attr MyEbus_MQTT room 12_Heizraum,MQTT2_DEVICE
    attr MyEbus_MQTT setList getKnown:noArg ebusd/list onlyknown\
      getAll:noArg ebusd/list
    attr MyEbus_MQTT stateFormat Status: \
    1:running\
    Signal: \
    2:signal\
    <br>Uptime: formatedUptime
    attr MyEbus_MQTT 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}
    attr MyEbus_MQTT verbose 0

    setstate FileLog_MQTT2_ebusd_21.2_1 active
    setstate FileLog_MQTT2_ebusd_21.2_1 2021-07-14 12:49:33 linesInTheFile 14

    setstate FileLog_MQTT2_ebusd_sc active
    setstate FileLog_MQTT2_ebusd_sc 2021-07-14 12:55:50 linesInTheFile 1686

    setstate MQTT2_ebusd_21.2_1 2021-07-14 08:49:26 IODev myMQTT_Server
    setstate MQTT2_ebusd_21.2_1 2021-07-14 12:49:33 Set_Action_value startconsumer
    setstate MQTT2_ebusd_21.2_1 2021-07-14 12:49:33 Set_DHWSetTemp_value 48.0
    setstate MQTT2_ebusd_21.2_1 2021-07-14 12:49:33 Set_SetTemp_value 5.00
    setstate MQTT2_ebusd_21.2_1 2021-07-14 12:49:33 Set_Status_value hotwater
    setstate MQTT2_ebusd_21.2_1 2021-07-14 08:50:24 subscriptions ebusd/#

    setstate MQTT2_ebusd_sc 2021-07-14 12:55:50 Act_DHWTemp_value 47.0
    setstate MQTT2_ebusd_sc 2021-07-14 12:55:50 Act_Error_value 0
    setstate MQTT2_ebusd_sc 2021-07-14 12:55:50 Act_ExternalTemp_value 20
    setstate MQTT2_ebusd_sc 2021-07-14 12:55:50 Act_Flame_value 0
    setstate MQTT2_ebusd_sc 2021-07-14 12:55:50 Act_GasValve1_value 0
    setstate MQTT2_ebusd_sc 2021-07-14 12:55:50 Act_GasValve2_value 0
    setstate MQTT2_ebusd_sc 2021-07-14 12:55:50 Act_Load_value 0
    setstate MQTT2_ebusd_sc 2021-07-14 12:55:50 Act_Operatingphase_value BrennerAus
    setstate MQTT2_ebusd_sc 2021-07-14 12:55:50 Act_Pump_value 0
    setstate MQTT2_ebusd_sc 2021-07-14 12:55:50 Act_SettingUV_value Heating
    setstate MQTT2_ebusd_sc 2021-07-14 12:55:50 Act_SoWi_value Summer
    setstate MQTT2_ebusd_sc 2021-07-14 12:55:50 Act_Status1_value 1
    setstate MQTT2_ebusd_sc 2021-07-14 12:55:50 Act_SupplySetTemp_value 8
    setstate MQTT2_ebusd_sc 2021-07-14 12:55:50 Act_SupplyTemp_value 25.0
    setstate MQTT2_ebusd_sc 2021-07-14 12:55:50 Act_TrendTemp_value 16.980
    setstate MQTT2_ebusd_sc 2021-07-14 12:55:50 Act_Ukn2_1_value 1
    setstate MQTT2_ebusd_sc 2021-07-14 12:55:50 Act_Ukn2_2_value 1
    setstate MQTT2_ebusd_sc 2021-07-14 12:55:50 Act_Ukn2_3_value 1
    setstate MQTT2_ebusd_sc 2021-07-14 12:55:50 Act_Ukn3_1_value 0
    setstate MQTT2_ebusd_sc 2021-07-14 12:55:50 Act_Ukn3_3_value 0
    setstate MQTT2_ebusd_sc 2021-07-14 12:55:50 Act_Ukn3_4_value 0
    setstate MQTT2_ebusd_sc 2021-07-14 12:55:50 Act_Ukn3_5_value 0
    setstate MQTT2_ebusd_sc 2021-07-14 12:55:50 Act_Ukn3_6_value 0
    setstate MQTT2_ebusd_sc 2021-07-14 12:55:50 Act_Ukn3_7_value 0
    setstate MQTT2_ebusd_sc 2021-07-14 12:55:50 Act_UknTemp_value 0.0
    setstate MQTT2_ebusd_sc 2021-07-14 08:49:26 IODev myMQTT_Server
    setstate MQTT2_ebusd_sc 2021-07-12 14:35:13 associatedWith MyEbus_MQTT

    setstate MyEbus_MQTT Status: \
    1:true\
    Signal: \
    2:true\
    <br>Uptime: 0 000 00:07
    setstate MyEbus_MQTT 2021-07-14 08:49:26 IODev myMQTT_Server
    setstate MyEbus_MQTT 2021-07-14 12:49:16 associatedWith MyEbus_MQTT
    setstate MyEbus_MQTT 2021-07-12 14:32:29 attrTemplateVersion 20200824
    setstate MyEbus_MQTT 2021-07-14 12:56:15 formatedUptime 0 000 00:07
    setstate MyEbus_MQTT 2021-07-14 12:49:03 running true
    setstate MyEbus_MQTT 2021-07-14 12:49:50 scan "finished"
    setstate MyEbus_MQTT 2021-07-14 12:49:20 signal true
    setstate MyEbus_MQTT 2021-07-12 14:32:29 state getKnown
    setstate MyEbus_MQTT 2021-07-14 12:51:50 updatecheck "OK"
    setstate MyEbus_MQTT 2021-07-14 12:56:15 uptime 432
    setstate MyEbus_MQTT 2021-07-14 12:49:03 version "ebusd 21.2.v21.2"

    Hätte ich die Devices löschen sollen?

    VG
    rob
    fhem@Raspi3B mit DietPi auf USB-SSD am aktiven Hub | Z-Wave Stick Aeotec | Zigbee Stick Conbee2 | nanoJeeLink | SIGNALduino@433 + @868 MHz | Denkovi USB-OW-Busmaster | config. Firmata@Arduino | EspEasy@WemosD1;Sonoff Basic  | MySensors@Arduino

    Offline beaune

    • Full Member
    • ***
    • Beiträge: 109
    Antw:ebus Weishaupt MQTT im Zusammenspiel
    « Antwort #9 am: 14 Juli 2021, 13:05:08 »
    Zur Info: ich hatte auch ein Problem mit der Codierung. Automatisch angelegt (vermutlich durch das Template eBus_Calormatic_TimeProgramm, kann ich aber nicht mehr im Detail nachvollziehen) wurde dieser Eintrag in der readingsList:ebusd/f47/ccTimer\x5c\x2eMonday:.* { json2nameValue($EVENT, 'ccTimer.Monday_', $JSONMAP)}So funktioniert das Reading nicht, jedenfalls nicht wenn man es so aktualisieren will:
    set mqtt publish ebusd/f47/hcTimer.Monday/get. Ich hab daher die readingList manuell angepasst:ebusd/f47/hcTimer.Monday:.* { json2nameValue($EVENT, 'hcTimer.Monday_', $JSONMAP) }Das war übrigens eines der Dinge, die den Eindruck vermittelt haben, dass die Templates irgendwie unfertig sind und man sie lieber nicht verwenden sollte...

    Offline rob

    • Full Member
    • ***
    • Beiträge: 368
    Antw:ebus Weishaupt MQTT im Zusammenspiel
    « Antwort #10 am: 14 Juli 2021, 13:18:41 »
    Supi, danke für den Wink.
    Jetzt kommen neue Readings rein:
         2021-07-14 13:14:38   scan.35_ID_value W
         2021-07-14 13:14:38   scan.35_MF_value Kromschroeder
         2021-07-14 13:14:38   scan.35_SW_value 2726
         2021-07-14 13:14:25   scan.f6_HW_value 0302
         2021-07-14 13:14:25   scan.f6_ID_value WWST?
         2021-07-14 13:14:25   scan.f6_MF_value Kromschroeder
         2021-07-14 13:14:25   scan.f6_SW_value 1200

    Einfach den Punkt setzen und gut.

    VG
    rob
    fhem@Raspi3B mit DietPi auf USB-SSD am aktiven Hub | Z-Wave Stick Aeotec | Zigbee Stick Conbee2 | nanoJeeLink | SIGNALduino@433 + @868 MHz | Denkovi USB-OW-Busmaster | config. Firmata@Arduino | EspEasy@WemosD1;Sonoff Basic  | MySensors@Arduino

    Offline Beta-User

    • Developer
    • Hero Member
    • ****
    • Beiträge: 15700
    Antw:ebus Weishaupt MQTT im Zusammenspiel
    « Antwort #11 am: 14 Juli 2021, 13:31:02 »
    @Rudi: M.E. ist "die Sache mit dem Punkt"  "unerwünschtes Verhalten" von M2D allgemein. Kannst du das bitte in die eine oder andere Richtung fixen? Bauchgefühl sagt: Punkt stehen lassen ist das kleinere Übel.

    @rob
    Hmm, irgendwie würde mich weiter interessieren, wo dieses ominöse Gerät "MQTT2_ebusd_21.2_1" entsteht. Konnte das grade jedenfalls nicht mit der in der file enthaltenen Topic/Payload-Kombi rekonsturieren. Gibt es in deiner Installation noch eine andere bridgeRegexp, aus der das kommen könnte?
    list TYPE=MQTT2_DEVICE bridgeRegexp
    MAn. kannst du diese beiden Geräte (M2D+fileLog) löschen.

    @beaune:
    Willkommen an Bord! (Und zur Klarstellung: ein "gutes attrTemplate" hätte das für dich gefixt ;) ... Erstellt wurde das Device übrigens durch die bridgeRegexp am "Zentraldevice" (und allgemeine M2DFunktionalität), nicht direkt durch attrTemplate)

    @rob:
    Bitte wirf in MQTT2_ebusd_sc den "Act_"-Prefix raus, sonst können wir da nicht mit "guten Readingnamen" weitermachen.
    Server: HP-T620@Debian 10, 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:MySensors, Weekday-&RandomTimer, Twilight,  AttrTemplate {u.a. mqtt2, mysensors, zwave}

    Offline rob

    • Full Member
    • ***
    • Beiträge: 368
    Antw:ebus Weishaupt MQTT im Zusammenspiel
    « Antwort #12 am: 14 Juli 2021, 13:50:00 »
    list TYPE=MQTT2_DEVICE bridgeRegexp sagt:
    MyEbus_MQTT              (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|solar|ui|uih|v\d\d|v81.\d|vd\d|vl\d|vr_\d\d|zeo)/.*:.* "$1_$2"
    (ebus..*?)/(global|broadcast|general|scan([^/]*))/.*:.* "$1"
    Beim Testen auf dem Testsystem ohne autocreate complex usw. kam auch dieses Device (als einziges). Durch den Split steht das Warmwasser drin - scheint der WW-Pufferspeicher zu sein. Habs aber erstmal gelöscht.

    Bitte wirf in MQTT2_ebusd_sc den "Act_"-Prefix raus, sonst können wir da nicht mit "guten Readingnamen" weitermachen.
    Ja, ist jetzt bereinigt. Sorry, hattest es schon geschrieben - ich aber nicht begriffen  ::)

    VG
    rob

    fhem@Raspi3B mit DietPi auf USB-SSD am aktiven Hub | Z-Wave Stick Aeotec | Zigbee Stick Conbee2 | nanoJeeLink | SIGNALduino@433 + @868 MHz | Denkovi USB-OW-Busmaster | config. Firmata@Arduino | EspEasy@WemosD1;Sonoff Basic  | MySensors@Arduino

    Offline rudolfkoenig

    • Administrator
    • Hero Member
    • *****
    • Beiträge: 24495
    Antw:ebus Weishaupt MQTT im Zusammenspiel
    « Antwort #13 am: 14 Juli 2021, 13:57:23 »
    Zitat
    @Rudi: M.E. ist "die Sache mit dem Punkt"  "unerwünschtes Verhalten" von M2D allgemein. Kannst du das bitte in die eine oder andere Richtung fixen? Bauchgefühl sagt: Punkt stehen lassen ist das kleinere Übel.

    Bevor ich irgendetwas unternehme, moeche ich das Problem verstehen.
    Ich sehe naemlich noch gar kein Problem, nur falsche Theorien wegen Codierungsfehler.

    Offline Beta-User

    • Developer
    • Hero Member
    • ****
    • Beiträge: 15700
    Antw:ebus Weishaupt MQTT im Zusammenspiel
    « Antwort #14 am: 14 Juli 2021, 14:09:11 »
    Bevor ich irgendetwas unternehme, moeche ich das Problem verstehen.
    Das "Problem" (bzw. die "konsolidierte Symptombeschreibung") sieht m.E. so aus:
    - Ein Client publisht unter einem Topic, der Punkte enthält.
    - M2D wandelt den beim automatischen Erstellen von readingList-Einträgen in "\x2e" um (vermutlich immer, in jedem Fall aber, wenn bridgeRegexp im Spiel ist).
    - Spätere publishes dieses Gerätes unter demselben Topic gehen verloren bzw. erzeugen nicht die erwarteten Readings/Werte

    Lösung also entweder: Der "eingehende Punkt" wird immer einheitlich konvertiert, (scheint derzeit irgendwie zu haken, sonst müsste es auch Readings geben), oder er bleibt halt stehen und kann mit einer "wildcard" verwechselt werden, so dass eventuell "zu viel" unter einem solchen Topic empfangen wird.

    Kurz: Es sollte irgendwie einheitlich sein, aber irgendwo geht halt im Moment was schief...


    @rob&beaune:
    Evtl. kann es gegen dieses "Phantom-Device" helfen, die bridgeRegexp schärfer zu schneiden. Würde mal folgendes in den Raum stellen:
    attr MyEbus_MQTT bridgeRegexp (ebus\S[^/]*?)/(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|solar|ui|uih|v\d\d|v81.\d|vd\d|vl\d|vr_\d\d|zeo)/.*:.* "$1_$2"\
    (ebus\S[^/]*?)/(global|broadcast|general|scan([^/]*))/.*:.* "$1"
    Server: HP-T620@Debian 10, 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:MySensors, Weekday-&RandomTimer, Twilight,  AttrTemplate {u.a. mqtt2, mysensors, zwave}

     

    decade-submarginal