Läuft: zigbee2mqtt mit MQTT2_SERVER und MQTT2_DEVICE

Begonnen von supernova1963, 23 September 2018, 19:17:21

Vorheriges Thema - Nächstes Thema

Beta-User

Zitat von: ulli am 19 Mai 2019, 10:14:48
Ein status online/offline wäre gut
Gibt es Readings?
Manchmal braucht es entspr. Einstellungen @zigbee2mqtt...
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

supernova1963

Zitat von: maclovlin am 19 Mai 2019, 09:22:21
Wäre dieses denn keine Option?
https://www.ikea.com/de/de/p/tradfri-signalverstaerker-10400408/

Diesen Artikel fand ich auch sehr interessant, habs bei mir umgesetzt.
https://www.metageek.com/training/resources/zigbee-wifi-coexistence.html

Vielen Dank für die Tips.
Ich hatte zunächst die cc2531 usb Controller und Repeater Variante ausprobiert.
Ob und wann ich es mit tradifi, hue, xiaomi etc. probiere, weiß ich noch nicht. Bis dahin bleibe ich erstmal bei 868 MHz.

Danke für die Hilfsbereitschaft,

Gernot

Beta-User

Zitat von: ulli am 19 Mai 2019, 10:14:48
Ein status online/offline wäre gut
Dafür müßte man erst mal zigbee2mqtt überreden, entsprechende Infos zu senden.

Sollte (dann aber für alle netzgebundenen Geräte!) mit dem Parameter "availability_timeout" in der configuration.yaml gehen.
(K.A., ob man auch eine Art Ping senden könnte...)
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

FunkOdyssey

Ich hatte an meine Stick testweise einen Osram-Plug angelernt. Diese danach aber wieder entfernt und anderweitig im Haus eingebunden.
Dennoch wird durch autocreate immer wieder ein MQTT2_DEVICE angelegt. Im FileLog sind nur folgende Zeilen enthalten. (Keine ON-Events vorhanden)

2019-08-13_09:41:04 MQTT2_zigbee_0xxxxxx_state: OFF
2019-08-13_09:41:04 MQTT2_zigbee_0xxxxxx_linkquality: 28


Kann mir jemand sagen, wie ich das nun dauerhaft loswerde?

Es steht im MQTT2-Zigbee-Device auch noch im Reading "devices".

TomLee

Eventuell weil das Gerät noch in der configuration.yaml steht ?

nano /opt/zigbee2mqtt/data/configuration.yaml

Gruß

Thomas

FunkOdyssey

Da ist devices leer. Aber in der database.db steht das Gerät noch.
Nur wie werde ich das los?

mark79

Zitat von: FunkOdyssey am 13 August 2019, 19:30:54
Da ist devices leer. Aber in der database.db steht das Gerät noch.
Nur wie werde ich das los?
Einfach gehts mit Fhem mit remove, über das MQTT2_zigbee_pi Device.
Ansonsten per Hand via: MQTT zigbee2mqtt/bridge/config/remove https://www.zigbee2mqtt.io/information/mqtt_topics_and_message_structure.html

Man sollte die Devices auch löschen, wenn man diese nicht mehr benötigt. Weil die Informationen auch auf dem Coordinator gespeichert werden und platz verbrauchen, welcher eh schon gering ist.
Rock64 4GB mit Debian Strech, FHEM im LXC, Sonoff Switches/Touch, HM Thermostate, HMUART/Zigbee2MQTT@MapleCUN, ESP RGBWW Wifi Controller, ESP8266 Door Sensor/Briefkastenwächter, BT CSL Stick, BT iTags, Alexa, FireTV, RPi2 mit Kodi, Xiaomi Vacuum v1/Smarthome Komponenten

maclovlin

Morgen,

ist vielleicht etwas offtopic, kann mich aber entsinnen das irgendjemand hier im Beitrag Probleme mit der Reichweite seiner CC2531 Sticks hatte.

Bin die Tage auf einen interessanten Mod gestoßen, wollte diesen euch nicht vorenthalten.

der Mod:
https://hackaday.io/project/163505-cc2531-usb-adapter-antenna-mod

und das passende Gehäuse dazu:
https://www.thingiverse.com/thing:3646828

Ich habe den Mod selber noch nicht ausprobiert, aber das Gehäuse ausgedruckt und für sehr gut befunden.

essera

Hi,

ich bin auf ein Phänomen gestoßen welches Rudi oder Beta evtl erklären können.
Ich habe ein Raspi System mit Fhem und Mosquitto für MQTT Devices und ein neues Docker System mit Fhem und MQTT2_Server in Fhem integriert.

Damit ich im Docker Fhem auch die MQTT Devices die sich auf Mosquitto angemeldet haben schalten kann, habe ich im Docker System auch ein MQTT Device für die Kommunikation mit dem Mosquitto Server angelegt.




Internals:
   BUF       
   DEF        192.168.178.26:1883
   DeviceName 192.168.178.26:1883
   FD         41
   FUUID      5c8991c1-f33f-fb0e-c276-00b79c0eaf90ff2a
   NAME       MOSQUITTO_Client
   NR         54
   PARTIAL   
   STATE      opened
   TYPE       MQTT2_CLIENT
   WBCallback
   clientId   MOSQUITTO_Client
   lastMsgTime 1570368570.07312
   nextOpenDelay 5
   READINGS:
     2019-10-05 19:52:51   state           opened
Attributes:
   alias      MOSQUITTO_Client
   room       mosquitto



Wenn nun per Autocreate ein neues MQTT2 Device vom internen MQTT2_Server erstellt wird zieht er als IO Device immer das Kommunikationsdevice Richtung Mosquitto Server an:


Internals:
   DEVICETOPIC waschkueche
   FUUID      5c996480-f33f-fb0e-d045-942d2e430c92e5d8
   IODev      MOSQUITTO_Client
   LASTInputDev MQTT2_FHEM_Server
   MOSQUITTO_Client_MSGCNT 123
   MOSQUITTO_Client_TIME 2019-10-06 15:13:59
   MQTT2_FHEM_Server_MSGCNT 4
   MQTT2_FHEM_Server_TIME 2019-10-06 15:16:21
   MSGCNT     127
   NAME       waschkueche
   NR         65
   STATE      off
   TYPE       MQTT2_DEVICE
   READINGS:
     2019-10-06 15:15:56   LoadAvg         24
     2019-10-06 15:15:56   POWER           OFF
     2019-10-06 15:15:56   Sleep           50
     2019-10-06 15:15:56   SleepMode       Dynamic
     2019-10-06 15:15:56   Time            2019-10-06T15:16:02
     2019-10-06 15:15:56   Uptime          0T00:00:17
     2019-10-06 15:15:56   Vcc             3.226
     2019-10-06 15:15:56   Wifi_AP         1
     2019-10-06 15:15:56   Wifi_BSSId      34:81:C4:E1:99:7A
     2019-10-06 15:15:56   Wifi_Channel    2
     2019-10-06 15:15:56   Wifi_Downtime   0T00:00:07
     2019-10-06 15:15:56   Wifi_LinkCount  1
     2019-10-06 15:15:56   Wifi_RSSI       100
     2019-10-06 15:15:56   Wifi_SSId       Turbonet
     2019-10-06 15:18:06   state           off
Attributes:
   IODev      MOSQUITTO_Client
   alias      Waschkueche.Licht
   autocreate 0
   readingList /SmartHome/Keller/Waschkueche/stat/POWER:.* state
/SmartHome/Keller/Waschkueche/tele/STATE:.* { json2nameValue($EVENT) }
   room       Licht,MQTT2_DEVICE
   setList    off:noArg  /SmartHome/Keller/Waschkueche/cmnd/power off
on:noArg  /SmartHome/Keller/Waschkueche/cmnd/power on
toggle:noArg  /SmartHome/Keller/Waschkueche/cmnd/power toggle



Ich muss in den Atributen dann das IO Device von Hand auf MQTT2_FHEM_Server setzen und danach ist alles gut.

Ich kann nicht nachvollziehen warum er das so macht , zumal er als LASTInputDev auch den MQTT2_FHEM_Server drin stehen hat. (siehe Listing)

Gibt es Erklärungen oder muss was anders gemacht werden oder Bug/Feature ??

VG,
Andreas.

rudolfkoenig

Falls es nicht explizit/manuell definiert wird, wird als IODev aus den Moeglichen die zuletzt Definierte genommen.
Wieso meinst Du, dass es nicht so gehoert?

essera

Weil das Mosquitto Device zu dem MQTT Broker mit der IP 192.168.178.26 zeigt (alte Umgebung 1) und der MQTT2_Server die IP 192.168.178.137 hat.
Somit geht nach dem Autocreate die Kommunikations in die "falsche Richtung"...

rudolfkoenig

Sorry, habe das Problem vorhin nicht verstanden.
Habe MQTT2_DEVICE erweitert, bitte testen.

essera

Hallo Rudi,

habe das Update eingespielt.
Nach Löschen und erneuter Erstellung über autocreate wurde (hier bei einem Shelly1) das IODev sowie LASTInputDev beide (wie erwartet) auf "MQTT2_FHEM_Server" gesetzt.
Scheint somit zu funktionieren - Vielen Dank dafür !!

OdfFhem

@rudolfkoenig

Zitat von: rudolfkoenig am 20 Dezember 2018, 08:57:20
Die model => Bildnamen-Umwandlung habe ich uebernommen.
supported-devices.js waehlt eine interessante Regexp-Alternative zu d.model.replace(/[\/: ]/g,' ').

Bislang hat die Bildanzeige in der neighbor map für mich immer funktioniert. Vor Kurzem habe ich einen SP 120 in mein System integriert; dieser hat für die Bildung einer Bild-URL eine spezielle model-Bezeichnung (SP 120), so dass eine Nachbearbeitung der model-Bezeichnung notwendig wird. Überraschenderweise wird aber für genau diesen eigentlich berücksichtigten Fall kein Bild angezeigt.


Ursache scheint die Verschachtelung der Search and Replace-Operationen zu sein.


  • Die erste Operation belegt laut regulärem Ausdruck die Match-Values $1 mit ieeeAddr und $2 mit model vor.

  • Schlägt die zweite Operation erfolgreich zu, werden die vorher geltenden Match-Values komplett zurückgesetzt, da laut regulärem Ausdruck keine neuen Match-Values gebildet werden sollen.

In einem solchen Fall kann der eigentlich richtig berechnete Bildname für eine Bild-URL nicht mehr ordnungsgemäß abgelegt werden - $1 entspricht nicht mehr der ieeeAddr und läuft auf folgenden Fehler:

2019.11.06 14:19:07 1: PERL WARNING: Use of uninitialized value $1 in hash element at ./FHEM/10_MQTT2_DEVICE.pm line 600.



Das "Retten" von $1 in einer Variablen und die Verwendung dieser Variablen zur Ablage des berechneten Bildnamens führt zur erfolgreichen Anzeige des Bildes.

  $dv =~ s@ieeeAddr":"([^"]+)"[^}]+model":"([^"]+)"@
+          my $ieeeAddr = $1;
           my $img = $2;
           $img =~ s+[/: ]+-+g; # Forum #91394: supported-devices.js
-          $img{$1} = "$img.jpg";
+          $img{$ieeeAddr} = "$img.jpg";
          @xeg;



Eine mögliche Lösung ... Es wäre schön, wenn die Änderung so oder so ähnlich ins MQTT2_DEVICE-Modul einfliessen würde.

rudolfkoenig

Kannst Du bitte einen Satz an Inputdaten liefern, damit ich es auch testen kann.