FHEM2MQTT2FHEM ... und seine Hürden

[TomLee]

Wo ist die MQTT_GENERIC_BRIDGE?

Ja auf dem Hauptsystem, wo sonst ?
Der ebusd verursacht die vielen Messages.

Code Auswählen Erweitern

defmod MGB MQTT_GENERIC_BRIDGE mqtt it_Steckdose1
attr MGB IODev MQTT2_Server

setstate MGB 2020-06-26 10:36:55 device-count 1
setstate MGB 2020-06-26 13:05:00 incoming-count 4585
setstate MGB 2020-06-26 12:19:20 outgoing-count 18
setstate MGB 2020-06-26 12:19:19 transmission-state outgoing publish sent
setstate MGB 2020-06-26 10:42:52 updated-reading-count 3
setstate MGB 2020-06-26 10:36:54 updated-set-count 0

Code Auswählen Erweitern

Generell sollte der 2. Server kein Ding sein; der läuft ja auf einem anderen Port, von daher erschließt sich mir jetzt grade das Problem bzw. der Zusammenhang nicht.

Ja, so stell ich mir das auch vor, frag bloss vorsichtig ob es einen Zusammenhang geben könnte, warum jetzt auf einmal, seit ich den Test-Pi installiert habe läuft sonos2mqtt ohne Probleme, war bisher immer sehr einfach alles zu handeln.

[Beta-User]

Na ja, es könnte auch auf dem Testsystem echte Hardware geben, und dann wäre die MQTT_GENERIC_BRIDGE ggf. nur dort bzw. auf beiden Systemen zu finden... (sinnvollerweise ggf. mit anderen Topic-Pfaden bzw. mind. einem 2. Basis-Pfad; so ein setup ist dann aber wirklich was für "Fortgeschrittene", da sollte man in der Lage sein, zu wissen, was woher und warum kommt und auf alle Fälle sicherstellen, dass "Clone" von Devices des jeweils anderen Systems nur als MQTT2_DEVICE existieren (Zur Klarstellung: es gibt (einige) User, die machen das "schon immer" mit dummy und "nur" MGB, aber das wäre dann für Experten und bietet mMn. eigentlich keinen Vorteil (mehr) gg. der Verwendung von MQTT2_DEVICE. Wollte nur darauf hinweisen, dass man das auch anders sehen kann, bitte durch diesen Annex nicht irrigieren lassen)).

Dass ebus die Quelle ist, überrascht nicht wirklich, aber ähnlich wie bei MQTT2_DEVICE selbst dürfte das - für sich genommen - unproblematisch sein. Allerdings wäre die Frage, wie und ob man die incoming-messages irgendwie begrenzen kann; da habe ich aber auf die Schnelle nichts gefunden (was nicht heißt, dass es nicht möglich sein kann). Ich meine dazu irgendwie im Ohr zu haben, dass der MAINTAINER mal geschrieben hätte, dass er die Last für die Auswertung gemessen hat und festgestellt, dass es sich nicht lohnt, eingehende Messages irgendwie vorzusortieren (das dürfte der Hintergrund zu der etwas kryptischen Info bei globalSubscribe sein).

[TomLee]

Da habe ich das mit dem ignoreRegexp-Ding jetzt mal in die Bridges zu zigbee2mqtt und MiLight reingebastelt und die GB-regexp angepaßt...

funzt super bei zigbee, aber wende ich nochmal das Bridge-Template an kommt das Dialogfeld mit

Code Auswählen Erweitern

Specify the unknown parameters for zigbee2mqtt_bridge:
base topic set in configuration.yaml of the zigbee2mqtt bridge obwohl in devicetopic der Name drin steht.

   
auch das milight-Bridge-Template funzt, aber auch hier kommt das Dialogfeld

Code Auswählen Erweitern

Specify the unknown parameters for esp_milight_hub_bridge:
BASE_ID typically is milight, in der RL steht aber der Topic drin

Code Auswählen Erweitern

milight/LWT:.* { json2nameValue($EVENT) }

und zusätzlich steht noch nach dem anwenden im Log:

Code Auswählen Erweitern


2020.06.26 14:28:59 1: PERL WARNING: Bareword found where operator expected at (eval 5101) line 1, near "9a"
2020.06.26 14:28:59 3: eval: {return 1 if milight/0x[0-9a-fA-F]{1,4}/.*/[0-8] ne "";;return 0}
2020.06.26 14:28:59 1: ERROR evaluating {return 1 if milight/0x[0-9a-fA-F]{1,4}/.*/[0-8] ne "";;return 0}: Bareword "milight" not allowed while "strict subs" in use at (eval 5101) line 1.
syntax error at (eval 5101) line 1, near "0x["
syntax error at (eval 5101) line 1, near "0}"

Was ich nicht verstehe : sollte nicht mit

Code Auswählen Erweitern

set DEVICE attrTemplate do_general_mqtt_cleanup ADD_TO_IO_IGNOREREGEXP=BASE_TOPIC/[A-Za-z0-9._]+/set

die ignoreregexp beim MQTT2_CLIENT nach dem anwenden der Templates eingetragen werden, das passiert nämlich nicht, sehe nix im Log, aber auch noch nicht geforscht.

[Beta-User]

Muß ich mir mal genauer und im Zusammenhang ansehen, evtl. fehlen da ein paar Klammern und Quotes... Wird dauern...

[TomLee]

Habs denk ich, aber wie es jetzt genau richtig ist weiß ich nicht, schalten Statusupdates, alles klappt ja.

In jedem angelegten Gerät steht in IODev der MQTT2_SERVER vom 2. Pi (der damit gar nichts zu tun hat) und dann gibts zusätzlich noch das Internal LASTInputDev in dem der MQTT2_CLIENT steht.

zwei Beispiele:

die steckdose

I

Code Auswählen Erweitern

nternals:
   DEVICETOPIC MQTT2_it_Steckdose1
   FUUID      5ef390bc-f33f-0353-4450-3705584a18a0d292
   IODev      MQTT2_Server
   LASTInputDev M2CLIENT
   M2CLIENT_MSGCNT 2
   M2CLIENT_TIME 2020-06-26 17:20:55
   MSGCNT     2
   NAME       MQTT2_it_Steckdose1
   NR         55
   STATE      off
   TYPE       MQTT2_DEVICE
   READINGS:
     2020-06-26 17:20:55   state           off
Attributes:
   IODev      MQTT2_Server
   readingList haus/wohnzimmer/steckdosen/state:.* state
   room       MQTT2_DEVICE
   setList    off:noArg haus/wohnzimmer/steckdosen/set off
on:noArg haus/wohnzimmer/steckdosen/set on
toggle:noArg haus/wohnzimmer/steckdosen/set toggle


die Milight-Bridge:

Code Auswählen Erweitern

Internals:
   CID        milight
   DEF        milight
   DEVICETOPIC speechrecognTesting
   FUUID      5ef486a7-f33f-0353-0834-fb173fdd8de0a448
   IODev      MQTT2_Server
   LASTInputDev M2CLIENT
   M2CLIENT_MSGCNT 2
   M2CLIENT_TIME 2020-06-26 17:12:10
   MSGCNT     2
   NAME       speechrecognTesting
   NR         59
   STATE      <a href="http://192.168.188.55" target="_blank">
connected
</a>Version:
1.10.5
   TYPE       MQTT2_DEVICE
   READINGS:
     2020-06-26 15:25:32   associatedWith  MQTT2_M2CLIENT
     2020-06-26 14:41:25   attrTemplateVersion 20200626
     2020-06-26 17:12:10   firmware        milight-hub
     2020-06-26 17:12:10   ip_address      192.168.188.55
     2020-06-26 17:12:10   reset_reason    Software/System restart
     2020-06-26 17:12:10   status          connected
     2020-06-26 17:12:10   version         1.10.5
Attributes:
   IODev      MQTT2_Server
   autocreate 1
   bridgeRegexp milight/[^/]*at[^/]+/(0x[0-9a-fA-F]{1,4})/.*/([0-8])?.*:.* "milight_$1_$2"
   devStateIcon connected:10px-kreis-gruen disconnected.*:10px-kreis-rot
   model      esp_milight_hub_bridge
   readingList milight/LWT:.* { json2nameValue($EVENT) }
   room       MQTT2_DEVICE
   setStateList on off
   stateFormat <a href="http://ip_address" target="_blank">
status
</a>Version:
version

[Beta-User]

Hmm, das mit dem "falschen" IO ist mMn. eine "unerwünschte Nebenwirkung" von DevIO, wenn man das "einfach so" machen läßt: Das greift sich immer das letzte prinzipiell passende IO aus der cfg (also das, das am weitesten hinten steht). Muß man manuell korrigieren und dürfte bei vielen Modulen auftreten (bei MySensors habe ich das im Modul verhindert/korrigiert, aber da ist der matching-Mechanismus auch anders als üblich (nicht unbedingt besser, eher ineffizienter)).

[TomLee]

Spricht was gegen

Code Auswählen Erweitern

{ InternalVal("DEVICE","LASTInputDev",undef) } habs im do_general_mqtt_cleanup-Template ausprobiert, klappt. Es landet aber immer noch keine ignoreregexp in MQTT2_CLIENT.

Wenn sich sonst noch jemand auskennt mit regex das steht weiterhin im Log :

Code Auswählen Erweitern

2020.06.26 18:23:55 1: PERL WARNING: Bareword found where operator expected at (eval 2032) line 1, near "9a"
2020.06.26 18:23:55 3: eval: {return 1 if milight/0x[0-9a-fA-F]{1,4}/.*/[0-8] ne "";;return 0}
2020.06.26 18:23:55 1: PERL WARNING: (Missing operator before a?)
2020.06.26 18:23:55 3: eval: {return 1 if milight/0x[0-9a-fA-F]{1,4}/.*/[0-8] ne "";;return 0}
2020.06.26 18:23:55 1: ERROR evaluating {return 1 if milight/0x[0-9a-fA-F]{1,4}/.*/[0-8] ne "";;return 0}: Bareword "milight" not allowed while "strict subs" in use at (eval 2032) line 1.
syntax error at (eval 2032) line 1, near "0x["
syntax error at (eval 2032) line 1, near "0}"

So sieht das Template aus:

Code Auswählen Erweitern

name:esp_milight_hub_bridge
filter:TYPE=MQTT2_DEVICE
desc:use this with Chris Mullins ESP-Milight-Hub. for further details visit https://github.com/sidoh/esp8266_milight_hub <br>Recommended stru$
order:X_01
par:BASE_ID;BASE_ID typically is milight;{ AttrVal("DEVICE","readingList","") =~ m,([^/]+)[/][^/]*at[^/]+[/].*:, ? $1 : undef }
attr DEVICE bridgeRegexp BASE_ID/[^/]*at[^/]+/(0x[0-9a-fA-F]{1,4})/.*/([0-8])?.*:.* "milight_$1_$2"
attr DEVICE autocreate 1
attr DEVICE setStateList on off
attr DEVICE stateFormat <a href="http://ip_address" target="_blank">\
status\
</a>Version: \
version
attr DEVICE devStateIcon connected:10px-kreis-gruen disconnected.*:10px-kreis-rot
set DEVICE attrTemplate do_general_mqtt_cleanup ADD_TO_IO_IGNOREREGEXP=BASE_ID/0x[0-9a-fA-F]{1,4}/.*/[0-8]
attr DEVICE model esp_milight_hub_bridge
setreading DEVICE attrTemplateVersion 20200626
{ AttrTemplate_Initialize() }


[Beta-User]

Spricht was gegen

Code Auswählen Erweitern

{ InternalVal("DEVICE","LASTInputDev",undef) } habs im do_general_mqtt_cleanup-Template ausprobiert, klappt. Es landet aber immer noch keine ignoreregexp in MQTT2_CLIENT.

Guter Vorschlag!

Was das andere angeht: Versuch's evtl. mal in Zeile 85 mit

Code Auswählen Erweitern

option:{return 1 if 'ADD_TO_IO_IGNOREREGEXP' ne "";;return 0}

[TomLee]

 

Code Auswählen Erweitern

defmod M2CLIENT MQTT2_CLIENT 192.168.188.26:1883
attr M2CLIENT autocreate simple
attr M2CLIENT ignoreRegexp milight/0x[0-9a-fA-F]{1,4}/.*/[0-8]
attr M2CLIENT room zMQTT
attr M2CLIENT username Thomas

setstate M2CLIENT opened
setstate M2CLIENT 2020-06-26 17:12:07 state opened

Und der regex greift auch der Pfad taucht nicht mehr in der GB auf.

[Beta-User]

 

Danke für's unermüdliche Testen und die Rückmeldung!

Bliebt die Frage, ob das setup insgesamt sinnig ist?
Ich könnte mir vorstellen, dass irgendwann irgendeiner mit dieser Art der Zwangsbeglückung nicht glücklich ist. Bin aber unschlüssig; letztlich wird es immer irgendein Kompromiss sein...

@all: Bitte um rechtzeitige Meldung, wenn ihr eher skeptisch seid, was diesen Teil angeht. Vermutlich ist es einfacher/schmerzfreier, das gleich reinzubauen, wie nachher wieder irgendwas drumrumzubasteln. Aber wenn, wäre die Frage, wie? Zuerst hatte ich an irgendeinen Marker bei global gedacht, zwischenzeitlich fände ich es eher zielführend, das wenn, dann entweder am IO unterzubringen, oder bei dem General-Bridge-Gerät (hier jeweils als userattr?). Da ließe es sich ggf. auch später noch einigermaßen schmerzfrei reinbasteln...?

@Rudi: Was mir auch leichtes Kopfzerbrechen bereitet: Derzeit sind einige (immer mehr) von diesen zentralen Funktionstemplates nur sichtbar, wenn man versucht, die grade auf ein Gerät mit einem speziellen Namen anzuwenden. Für die Entwicklung und das Testen war das ok, aber irgendwie sollte da (bei Bedarf bzw. auf Wunsch) mehr Transparenz her. Da die templates innerhalb des Systems immer verfügbar sein "müssen", ist prereq: nicht zielführend, und filter: ist reine devspec, so dass man nicht so einfach auf externe Infos zugreifen kann. Wenn letzteres möglich wäre, könnte man es z.B. mit dem global-Attribut "showInternalValues" verknüpfen? Das hat sowieso die Funktion einer Art "Expertenansicht". Die entsprechenden Template-Namen mit einem Punkt zu beginnen wäre vermutlich vom Aufwand her nicht das große Problem, einfacher wäre, jeweils ein filter2: dazuzuschreiben (oder irgendwas in der Art halt).
Bin da aber nicht festgelegt und das ganze ist auch nicht dringlich; vielleicht fällt dir ja was cleveres ein ?

[Beta-User]

Zur Info: eben habe ich noch ein update ins svn geschust. Da ist das mit den Quotes drin und auch die beiden allgemeinen ignoreRegexp-Templates habe ich etwas umgebaut, Hinweise erweitert...

Wie immer: feedback ist willkommen!

[TomLee]

{ { InternalVal("DEVICE","LASTInputDev",AttrVal("DEVICE","IODev",undef)) }

Müsste noch korrigiert werden



Es bleibt bei

Code Auswählen Erweitern

Specify the unknown parameters for esp_milight_hub_bridge:
BASE_ID typically is milight

trotz das der Pfad in der RL vorhanden ist.

Vorab kurz zu den set-Zweigen: Wie geschrieben, muß man sich darum gesondert kümmern und am besten diese Teile über eine ignoreRegexp am IO "entsorgen". In der Hinsicht könnten wir allenfalls eine Art "typisierter Vorschlag" machen, was die von einem Template eventuell erkennbare Struktur angeht (z.B.  fhemnn/.*/set), aber das erschlägt leider die ganzen set-Zweige von "irgendwelchen" Diensten wie (sonos|zigbee|.*)2mqtt vermutlich nicht so einfach (wobei man ggf. mal den Versuch unternehmen könnte, das 2mqtt als "General-Präfix" iVm. dem set-Ende zu verwenden?)...

Mach mal bitte einen Vorschlag zu den Tasmota set-Zweigen, egal wie ich es machen würde du löst es am Ende eh dann wieder mit einer anderen regex.

Code Auswählen Erweitern

M2CLIENT:cmnd/sonoffDual_schaltschrank/POWER1:.* POWER1
M2CLIENT:cmnd/tasmota/POWER1:.* POWER1
M2CLIENT:cmnd/tasmotairwz/IRSend:.* { json2nameValue($EVENT) }

[Beta-User]

 

Neues update ist drin, ich hoffe, auch den Milight-Teil irgendwie erwischt zu haben...

Es gab schon Vorschläge betr. die Shelly- und Tasmota-Zweige. Die habe ich jetzt "entzerrt" und das Basistemplate modularisiert, so dass man jetzt auch die einzelnen Teile gesondert aufrufen kann.

[rudolfkoenig]

Hmm, das mit dem "falschen" IO ist mMn. eine "unerwünschte Nebenwirkung" von DevIO, wenn man das "einfach so" machen läßt: Das greift sich immer das letzte prinzipiell passende IO aus der cfg

Stimmt im Prinzip, nur im Detail nicht
Die Zuordnung macht fhem.pl in AssignIoPort, was ueblicherweise aus dem Modul-eigenen DefineFn aufgerufen wird. Falls $proposed nicht gesetzt ist, wird die zuletzt definierte "passende" IO-Geraet zugewiesen, auch wenn sie noch nicht in fhem.cfg steht.

@Beta-User: wg. dem "Kopfzerbrechen": kannst Du mir bitte das Problem nochmal schildern, gerne mit einem konkreten Beispiel?

[TomLee]

(Ähm, diese scan-Geschichten: Sind das auch Anweisungen? (=>ignoreRegexp)).

Nein.

Code Auswählen Erweitern

defmod MQTT2_ebusd_Bridge MQTT2_DEVICE ebusd
attr MQTT2_ebusd_Bridge IODev MQTT2_Server
attr MQTT2_ebusd_Bridge autocreate 1
attr MQTT2_ebusd_Bridge 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_Bridge devStateIcon 1.true:it_net 1.false:it_net@red  2.true:lan_rs485 2.false:lan_rs485@red
attr MQTT2_ebusd_Bridge devStateStyle style="text-align:right"
attr MQTT2_ebusd_Bridge group MQTT2_Bridges
attr MQTT2_ebusd_Bridge icon mqtt_bridge_2
attr MQTT2_ebusd_Bridge model eBus_daemon_splitter
attr MQTT2_ebusd_Bridge readingList ebusd/global/uptime:.* uptime\
ebusd/global/running:.* running\
ebusd/global/version:.* version\
ebusd/global/signal:.* signal\
ebusd/global/updatecheck:.* updatecheck\
ebusd/scan\.08/id:.* { json2nameValue($EVENT, 'id_', $JSONMAP) }\
ebusd/scan\.ec/:.* { json2nameValue($EVENT, 'scan.ec_', $JSONMAP) }\
ebusd/scan\.ec/id:.* { json2nameValue($EVENT, 'id_', $JSONMAP) }
attr MQTT2_ebusd_Bridge room MQTT2_DEVICE
attr MQTT2_ebusd_Bridge setList getKnown:noArg ebusd/list onlyknown\
  getAll:noArg ebusd/list
attr MQTT2_ebusd_Bridge stateFormat Status: \
1:running\
Signal: \
2:signal\
<br>Uptime: formatedUptime
attr MQTT2_ebusd_Bridge 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}

setstate MQTT2_ebusd_Bridge Status: \
1:true\
Signal: \
2:true\
<br>Uptime: 0 001 05:36
setstate MQTT2_ebusd_Bridge 2020-01-05 14:59:35 associatedWith MQTT2_ebusd_Bridge
setstate MQTT2_ebusd_Bridge 2020-06-28 07:13:52 formatedUptime 0 001 05:36
setstate MQTT2_ebusd_Bridge 2020-01-04 18:13:05 id_counter_value 005260
setstate MQTT2_ebusd_Bridge 2020-01-04 18:13:05 id_prefix_value 21
setstate MQTT2_ebusd_Bridge 2020-01-04 18:13:05 id_product_value 0010010678
setstate MQTT2_ebusd_Bridge 2020-01-04 18:13:05 id_suffix_value N2
setstate MQTT2_ebusd_Bridge 2020-01-04 18:13:05 id_supplier_value 3100
setstate MQTT2_ebusd_Bridge 2020-01-04 18:13:05 id_week_value 34
setstate MQTT2_ebusd_Bridge 2020-01-04 18:13:05 id_year_value 17
setstate MQTT2_ebusd_Bridge 2020-06-27 01:37:26 running true
setstate MQTT2_ebusd_Bridge 2019-12-24 16:30:04 scan.ec_HW_value 6403
setstate MQTT2_ebusd_Bridge 2019-12-24 16:30:04 scan.ec_ID_value 70000
setstate MQTT2_ebusd_Bridge 2019-12-24 16:30:04 scan.ec_MF_value Vaillant
setstate MQTT2_ebusd_Bridge 2019-12-24 16:30:04 scan.ec_SW_value 0510
setstate MQTT2_ebusd_Bridge 2020-06-27 01:37:42 signal true
setstate MQTT2_ebusd_Bridge 2019-12-22 16:47:52 state getKnown
setstate MQTT2_ebusd_Bridge 2020-06-27 01:39:44 updatecheck "version 3.4 available"
setstate MQTT2_ebusd_Bridge 2020-06-28 07:13:52 uptime 106586
setstate MQTT2_ebusd_Bridge 2020-06-27 01:37:26 version "ebusd 3.3.v3.3"