Läuft: zigbee2mqtt mit MQTT2_SERVER und MQTT2_DEVICE

[Beta-User]

Ja, 1:1 an diese Anleitung habe ich mich gehalten. Nur eben anstatt user pi den user dieter verwendet.
Die Rechte habe ich dann so gesetzt:

Code Auswählen Erweitern

sudo chown -R dieter:dieter /opt/zigbee2mqtt

Why? M.E. sollte das der "normale" admin-User sein; du hast vermutlich auch einen user pi (unterstellt, du bist auf einem Pi; sonst wäre das eben der User, der für admin-Zwecke "eigentlich" angelegt wurde; das scheint jedenfalls nicht dieter zu sein)

Im Übrigen ist das hier ziemlich OT. Bitte ggf. einen separaten Thread aufmachen bzw. bei kkoenk nachfragen!

[dk3572]

Ok, dann abschließend zur Rechtefrage.
Ich habe auf einem Intel Nuc Ubuntu 18.04 installiert und hierbei den user dieter angelegt.
Unter diesem user habe ich auch alles nach der Anleitung ausgeführt. War das falsch?
Auch wenn ziemlich OT wäre ich für Hilfe dankbar das ich mit dem eigentlichen Thema weiter komme.
Danke.

[Beta-User]

M.E. ist das für einen Debian-Rechner an sich richtig so; es gibt dann aber root und dieter, wobei root anders als bei raspbian nicht deaktiviert ist.

An sich sollte das dann aber ähnlich einzurichten sein wie bei FHEM: da wird durch das deb-Paket ein spezieller user eingerichtet, und der hat dann auch das Recht, den (FHEM-) Dienst zu starten. Würde daher vorschlagen, das Verzeichnis mit einem neuen user (zigtomqtt) zu berechtigen (zigtomqtt:dialout), diesen user der Gruppe dialout hinzuzufügen (sonst darf er den stick nicht nutzen, was ggf. hier auch das Problem ist) und dann mal zu recherchieren, was sonst noch erforderlich ist, dass systemd das frißt. "sudo" darf dabei m.E. nicht vorkommen, aber ich bin da auch nicht der Spezialist und muß sowas auch erst recherchieren...

Bitte ggf. ein gesondertes Thema aufmachen (gehört m.E. nach zigbee, wenn du unbedingt hier im Forum bleiben willst. Kannst gerne einen Link von hier dahin setzen.)

EDIT: ggf. hilft das hier, was die Angabe der Rechte usw. angeht: https://forum.fhem.de/index.php?topic=54271.0

[dk3572]

Hallo,

muss hier noch mal nachfragen.
Nach Anpassung von Rechten habe ich es mittlerweile zum laufen gebracht. Auch ohne sudo.
Einzig die Aktivierung von ssl funktioniert nicht.
Sobald ich im MQTT2_Server ssl 1 und sslVersion SSLv23:!SSLv3:!SSLv2 oder TLSv12:!SSLv3 setze, erhalte ich im Sekundentakt diese Meldung und der Stick bleibt offline:

Code Auswählen Erweitern

MQTT2_SERVER SSL/HTTPS error:  SSL accept attempt failed error:1408F10B:SSL routines:ssl3_get_record:wrong version number (peer: 127.0.0.1)

In global ist die sslVersion SSLv23:!SSLv3:!SSLv2 gesetzt.

Und falls das relevant ist, bei einem Neustart von Fhem erhalte ich diese Meldung:

Code Auswählen Erweitern

FHEMWEB SSL/HTTPS error:  SSL accept attempt failed error:1408F09C:SSL routines:ssl3_get_record:http request (peer: 192.xxx.xxx.xx)
(IP vom Ubuntu Server auf dem Fhem läuft)

Kann mir hierbei jemand weiterhelfen?

Danke un VG
Dieter

[Beta-User]

Ok dann werde ich erstmal warten und schauen was so kommt (;

Könntest du dir vielleicht noch ein Device parallel anlegen und mit deiner Lampe mal folgendes testen und mir sagen wie es dir gefällt bzw. ob alles funktioniert, dann würde ich vielleicht nochmal alle templates ein wenig danach anpassen:

Code Auswählen Erweitern

Attributes:
   IODev      mqttServer
   devStateIcon {zigbee2mqtt_devStateIcon255($name)}
   model      L_02c_zigbee2mqtt_light_rgb_hex
   readingList zigbee2mqtt/testdevice:.* { json2nameValue($EVENT) }
   setList    on:noArg zigbee2mqtt/testdevice/set {"state":"ON"}
  off:noArg zigbee2mqtt/testdevice/set {"state":"OFF"}
  brightness:colorpicker,BRI,0,5,255 zigbee2mqtt/testdevice/set {"state":"on","brightness":"$EVTPART1"}
  color:colorpicker,HEX,0,15,255 zigbee2mqtt/testdevice/set {"state":"on","color":{"hex":"#$EVTPART1"}}
   setStateList on off
   stateFormat {lc ReadingsVal("$name","state",0)}
   userReadings state {if(ReadingsVal($name,"state","") eq "OFF") {return "off"} else {return "on"}},
brightness {(split ' ',ReadingsVal($name,"brightness",0))[1]},
color:color_y.* {Color::xyY2hex(ReadingsVal($name,"color_x",0),ReadingsVal($name,"color_y",0),ReadingsVal($name,"brightness",255))}
   webCmd     toggle:on:off:brightness:color

Und danke für die Informationen zu json2nameValue, ich werde mal schauen was ich da so noch zu herausfinde bzw. hinbekomme um die readings ohne das setzen der userReadings richtig angezeigt zu bekommen 

Sorry, bin leider erst jetzt dazu gekommen, mir das mal anzusehen.

Leider kann ich ohne raw-Infos schlecht ein Test-Device anlegen, und meine tint liegt im Moment auch im Keller... Daher nur mal theoretische Rückmeldung:
Ich fand es schon immer nicht gut, mit userreadings den state zu verändern und würde ungern "set on" mit "off" überschrieben wissen. Stimmt zwar noch, aber man sieht ggf. das Verbindungsproblem nicht mehr, das besteht, wenn das Device länger auf "set x" steht. Bei "set off" stimmt die Info dann definitiv nicht.

brightness verstehe ich nicht, da müßte ich das heutige Reading kennen, daher weiß ich auch nicht, welche Auswirkungen das auf die color-Funktion hat.


@Dieter: Das ist m.E. kein wirkliches zigbee2mqtt-Problem. Mach' doch einfach zu diesem speziellen Thema einen eigenen Thread auf. Ich würde annehmen, dass die Absicherung des Servers noch andere interessiert, die nicht zigbee2mqtt machen. Die finden das hier vermutlich nicht...

[essera]

Hi,

ich muss mal sagen, dass das Zigbee Modul und die Unterstützung in Fhem inzwischen einen Reifegrad erreicht hat der echt SUPER ist.
Die Autocreate Funktion und die Templates machen es sehr einfach die unterschiedlichtsten Zigbee Geräte zum Laufen zu bekommen. Danke dafür allen Beteiligten!

Inzwischen ist nur noch Feintuning angesagt.

Eine Sache die ich ausprobiert habe ist den Parameter "friendly Name" in der configuration.yaml zu setzen.

Code Auswählen Erweitern


'0x00158d000257d9e6':
    friendly_name: 'keller_move'
    retain: false


Die Autocreate Funktion legt dann folgendes Device an:

Code Auswählen Erweitern



Internals:
   CFGFN     
   CID        zigbee_keller
   DEF        zigbee_keller
   DEVICETOPIC MQTT2_zigbee_keller
   FUUID      5c8eb095-f33f-fb0e-f71e-4b9b390e08fe3b1d
   IODev      MOSQUITTO_Client
   LASTInputDev MQTT2_FHEM_Server
   MQTT2_FHEM_Server_MSGCNT 12
   MQTT2_FHEM_Server_TIME 2019-03-17 21:57:26
   MSGCNT     12
   [b]NAME       MQTT2_zigbee_keller[/b]
   NR         14871
   STATE      ???
   TYPE       MQTT2_DEVICE
   READINGS:
     2019-03-17 21:39:49   associatedWith  MQTT2_zigbee_pi
     2019-03-17 21:57:26   illuminance     287
     2019-03-17 21:57:26   linkquality     7
     2019-03-17 21:57:26   occupancy       true
Attributes:
   IODev      MOSQUITTO_Client
   readingList zigbee2mqtt/keller_move:.* { json2nameValue($EVENT) }
   room       MQTT2_DEVICE


Man sieht also, dass der friendly name in der Benennung des Device nur bis zum "_" übernommen wurde. Ein Versuch den Name mit einem "." zu trennen "keller.bewegung führte zum gleichen Namen- hinter dem Trennzeichen wird abgeschnitten.
Für die readingList wurde der Name komplett und richtig übernommen.

Ist das so gewollt oder kann man das evtl. anpassen ? (wie gesagt - Feintuning - man kann ja in Fhem auch mit Alias oder umbenennen arbeiten.)

Grüße,
Andreas.

[rudolfkoenig]

Man sieht also, dass der friendly name in der Benennung des Device nur bis zum "_" übernommen wurde.

Tut mir leid, ich sehe das nicht.
Ich sehe, dass der Name aus MQTT_<clientId> gebildet wurde.
Dabei wird in clientId alles ausser a-zA-Z0-9._ nach _ gewandelt, aber das ist in diesem Fall wohl nicht relevant.
Welche Auswirkungen friendly_name hat, ist mir aber nicht bekannt, evtl. uebersehe ich etwas.

[essera]

Tut mir leid, ich sehe das nicht.
Ich sehe, dass der Name aus MQTT_<clientId> gebildet wurde.
Dabei wird in clientId alles ausser a-zA-Z0-9._ nach _ gewandelt, aber das ist in diesem Fall wohl nicht relevant.
Welche Auswirkungen friendly_name hat, ist mir aber nicht bekannt, evtl. uebersehe ich etwas.

Mit dem Parameter "friendly_name" übermittelt das zigbee2mqtt Modul sozusagen einen Alias für den recht kryptischen Seriennummern Namen des Device.

Das Device wurde ja auch angelegt wie im Listing zu sehen ist. Aber eben nicht der komplette friendly_name (keller_move), sondern "MQTT2_zigbee_keller".
Der Stringteil "_move" aus dem "friendly_name" ist bei der Namensgebung unterm Tisch gefallen.

[OdfFhem]

@essera
Für die Namensgebung entscheidend ist das Attribut bridgeRegexp in Deinem
associatedWith-Device MQTT2_zigbee_pi.

[rudolfkoenig]

Mit dem Parameter "friendly_name" übermittelt das zigbee2mqtt Modul sozusagen einen Alias für den recht kryptischen Seriennummern Namen des Device.

Wo bzw. wie?
Wie geschrieben: MQTT2_DEVICE nimmt den clientId fuer den Namen.
Bei einem externen MQTT Server (d.h. ueber MQTT2_CLIENT) steht FHEM diese Information nicht zur Verfuegung, und wird deswegen per bridgeRegexp "dazugedichtet".

[Beta-User]

@Rudi:
Ist es eigentlich irgendwie möglich, den HASH mit den gesammelten bridgeRegexp-Ausdrücken irgendwie/irgendwo angezeigt zu bekommen?

Wenn nein: wäre es viel Aufwand, das als "get" an den MQTT2-IO's hinzuzufügen?

Zum Hintergrund: Vermutlich ist nicht nur  @essera grade nicht klar, welche bei ihm wirksam sind; ich würde darauf tippen, dass das z.B. auch der Hintergrund dieses Beitrags ist: https://forum.fhem.de/index.php/topic,94494.msg920202.html#msg920202

(Ergänzend: ist es so, dass neue bridgeRegexp-Ausdrücke einfach zusätzlich in den HASH geschrieben werden, man also z.B. 3x diesen Ausdrücke drin stehen hat, wenn man 3x das 00_General...-template anwendet? Das ist m.E. an sich ok, führt aber zu anderen "statistischen Verteilungen" bei der Neuanlage von Devices und eben der irrigen Annahme, dass die bredgeRegepx (komplett) weg sei, wenn man das zugrundeliegende Device löscht.)

[rudolfkoenig]

Ist es eigentlich irgendwie möglich, den HASH mit den gesammelten bridgeRegexp-Ausdrücken irgendwie/irgendwo angezeigt zu bekommen?

Was spricht gegen "list .* bridgeRegexp" ?
Mit folgendem Ausdruck kriegt man die interne Liste zurueck:

Code Auswählen Erweitern

{ my $b=$modules{MQTT2_DEVICE}{defptr}{bridge};; join("\n", map { "regexp:$_ name:$b->{$_}{name} parent:$b->{$_}{parent}" } keys %{$b}) }bin aber nicht sicher, ob es wirklich hilft.
Wenn doch, dann koennen wir ueber ein get nachdenken.

[Beta-User]

Was spricht gegen "list .* bridgeRegexp" ?Mit folgendem Ausdruck kriegt man die interne Liste zurueck:

Code Auswählen Erweitern

{ my $b=$modules{MQTT2_DEVICE}{defptr}{bridge};; join("\n", map { "regexp:$_ name:$b->{$_}{name} parent:$b->{$_}{parent}" } keys %{$b}) }

"An sich" spricht nichts gegen das list, aber: eben habe ich auf einem Testsystem dann mal zwei Devices angelegt mit derselben bridgeRegexp (schon klar, dass das ggf. wenig Sinn macht...). Im List erhalte ich beide Devices, in der internen Liste nur das, was später definiert wurde, also effektiv wirksam ist.
Dann habe ich im einen eine Änderung vorgenommen (ebus-splitter, dort "$1_bai" zu "$1_bai2" geändert).
Ergebnis: es findet sich _nur noch_ das letztere Device in der Liste.

Dann: die bridgeRegepx am 2. Gerät gelöscht.
Das list sieht erwartungsgemäß aus, aber schau mal nach, was dann in der internen Liste steht... (die letzte bridgeRegexp aus der Kopie).

Fazit: "Eigentlich" brauche ich die Liste (bzw. das "get") nicht, was wir benötigen, ist eine korrekte interne Verwaltung der Angabe in so einem Fall, oder? Also eine komplette Neuanlage unter Berücksichtigung aller Devices, wenn irgendwo was passendes an einem relevanten Device geändert wird bzw. dieses Device/dessen bridgeRegexp gelöscht wird.

[rudolfkoenig]

habe ich auf einem Testsystem dann mal zwei Devices angelegt mit derselben bridgeRegexp

Und ich dachte, das waeren exotische Faelle, wo ein Neustart verschmerzbar ist.
Habs gefixt, aendern/loeschen/umbenennen sollte jetzt mit bridgeRegexp funktionieren.

[Beta-User]

Und ich dachte, das waeren exotische Faelle, wo ein Neustart verschmerzbar ist.
Habs gefixt, aendern/loeschen/umbenennen sollte jetzt mit bridgeRegexp funktionieren.

Dachte auch mal, das wäre exotisch...
Aber nachdem dan auch TomLee beim Testen für den ebusd darüber gestolpert war und auch bei dem anderen Thread die Vermutung nahe lag, dass da in einem "falschen" bridgeRegexp-Rest die tiefere Ursache war, wollte ich das halt mal nachstellen.

Wie dem auch sei: (ungetestetes) Danke für's fixen!