Zigbee Device offline, über Putty und zigbee2mqtt funktioniert alles

Begonnen von D3ltorohd, 27 Juni 2019, 21:02:37

Vorheriges Thema - Nächstes Thema

D3ltorohd

Hallo Com,

ich habe seit heute ein Problem, ich kann irgendwie nicht mehr zu meinem Zigbee Stick connecten. In FHEM steht offline und es wird auch nicht mehr auf den Schalter reagiert. Wenn ich das ganze im Terminal anschaue, hat Zigbee2MQTT eine Verbindung zum Stick und der Kontakt wird auch wunderbar erkannt.

In der Log habe ich nur folgendes gefunden, kann sein das hier das Problem liegt ?

2019.06.27 20:58:41 1: ERROR: Unhandled packet PUBCOMP, disconneting MQTT_Broker_127.0.0.1_40820
2019.06.27 20:58:41 1: 127.0.0.1:1883 disconnected, waiting to reappear (mqtt)
2019.06.27 20:58:42 1: 127.0.0.1:1883 reappeared (mqtt)


Falls ihr noch andere Infos braucht bitte bescheid sagen, bin recht neu in Fhem.

Grüße,
Base : Intel NUC Debian 9, FHEM aktuell || Zigbee (Coordinator FW Z-Stack 1.2 default Koenkk) || MaxCUL (culfw V 1.67 nanoCUL868) || SIGNALduino 433MHz (V 3.3.2.1-rc8 ) || Shelly s1

rudolfkoenig

Zitat2019.06.27 20:58:41 1: ERROR: Unhandled packet PUBCOMP, disconneting MQTT_Broker_127.0.0.1_40820
- ich gehe davon aus, dass Du MQTT2_SERVER verwendest.
- die Gegenseite schickt ein Paket (PUBCOMP), was bei PUBLISH mit QoS 2 verwendet wird, was MQTT2_SERVER nicht unterstuetzt.
- wie es dazu kam, und wer genau daran Schuld ist, kann ich nur sagen, wenn ich ein "attr mqtt2_server verbose 5" Log der Kommunikation sehe
- wenn das "ploetzlich" auftrat, dann tippe ich auf eine Aenderung der Zigbee2mqtt Seite, da ich MQTT2_SERVER diesbezueglich seit vielen Monaten nicht angefasst habe
- wenn moeglich, wuerde ich in der zigbee2mqtt Konfiguration QoS 2 abschalten.

D3ltorohd

Zitat von: rudolfkoenig am 28 Juni 2019, 09:14:38
- ich gehe davon aus, dass Du MQTT2_SERVER verwendest.
- die Gegenseite schickt ein Paket (PUBCOMP), was bei PUBLISH mit QoS 2 verwendet wird, was MQTT2_SERVER nicht unterstuetzt.
- wie es dazu kam, und wer genau daran Schuld ist, kann ich nur sagen, wenn ich ein "attr mqtt2_server verbose 5" Log der Kommunikation sehe
- wenn das "ploetzlich" auftrat, dann tippe ich auf eine Aenderung der Zigbee2mqtt Seite, da ich MQTT2_SERVER diesbezueglich seit vielen Monaten nicht angefasst habe
- wenn moeglich, wuerde ich in der zigbee2mqtt Konfiguration QoS 2 abschalten.

Vielen Dank erst mal fürs Antworten, genau ich nutze den MQTT2 Server, diesen hatte ich extra installiert wegen Zigbee2MQTT, ich hatte das auch soweit konfiguriert und es lief auch einige Tage. Da ich mit dem Fensterkontakt und ASC am testen bin ist mir aufgefallen das dort offline stand. Seit es lief, habe ich nichts wissentlich geändert. Oder updatet sich Zigbee2MQTT automatisch ? Also die Z2M Config sieht recht mager aus, Bezüglich deseim QoS 2 habe ich nichts gesehen.

Wenn du mir hilfst und sagst wie ich ein attr mqtt2_server verbose 5 Log erstelle, kann ich dir das gerne geben.

EDIT:: Ich glaub ich hab's sieht das nach dem aus was du brauchst ?

2019.06.28 16:34:26 5: PINGREQ: (192)(0)
2019.06.28 16:34:26 4: MQTT_Broker_127.0.0.1_40826 MY_CLIENT_ID PINGREQ
2019.06.28 16:34:50 5: PINGREQ: (192)(0)
2019.06.28 16:34:50 4: MQTT_Broker_127.0.0.1_40828 NetMQTTpm1825 PINGREQ
2019.06.28 16:35:24 5: PUBLISH: 2%(0)!zigbee2mqtt/bridge/config/devices(0)(15)
2019.06.28 16:35:24 4: MQTT_Broker_127.0.0.1_40828 NetMQTTpm1825 PUBLISH zigbee2mqtt/bridge/config/devices:
2019.06.28 16:35:24 5: MQTT_Broker_127.0.0.1_40826 MY_CLIENT_ID => zigbee2mqtt/bridge/config/devices:
2019.06.28 16:35:24 5: MQTT_Broker: dispatch autocreate=no\000NetMQTTpm1825\000zigbee2mqtt/bridge/config/devices\000
2019.06.28 16:35:24 5: PUBLISH: 2!(0)(29)xiaomi/cmnd/bridge/getDevices(0)(16)
2019.06.28 16:35:24 4: MQTT_Broker_127.0.0.1_40828 NetMQTTpm1825 PUBLISH xiaomi/cmnd/bridge/getDevices:
2019.06.28 16:35:24 5: MQTT_Broker: dispatch autocreate=no\000NetMQTTpm1825\000xiaomi/cmnd/bridge/getDevices\000
2019.06.28 16:35:24 5: PUBLISH: 0(253)(2)(0)(22)zigbee2mqtt/bridge/log{"type":"devices","message":[{"ieeeAddr":"0x00124b0018e1f6b9","type":"Coordinator"},{"ieeeAddr":"0x00158d0002e8bbbc","type":"EndDevice","model":"MCCGQ01LM","friendly_name":"Terrasse_Sensor","nwkAddr":42418,"manufId":4151,"manufName":"LUMI","powerSource":"Battery","modelId":"lumi.sensor_magnet","hwVersion":2,"swBuildId":"3000-0001","dateCode":"20150424"}]}
2019.06.28 16:35:24 4: MQTT_Broker_127.0.0.1_40826 MY_CLIENT_ID PUBLISH zigbee2mqtt/bridge/log:{"type":"devices","message":[{"ieeeAddr":"0x00124b0018e1f6b9","type":"Coordinator"},{"ieeeAddr":"0x00158d0002e8bbbc","type":"EndDevice","model":"MCCGQ01LM","friendly_name":"Terrasse_Sensor","nwkAddr":42418,"manufId":4151,"manufName":"LUMI","powerSource":"Battery","modelId":"lumi.sensor_magnet","hwVersion":2,"swBuildId":"3000-0001","dateCode":"20150424"}]}
2019.06.28 16:35:24 5: MQTT_Broker: dispatch autocreate=no\000MY_CLIENT_ID\000zigbee2mqtt/bridge/log\000{"type":"devices","message":[{"ieeeAddr":"0x00124b0018e1f6b9","type":"Coordinator"},{"ieeeAddr":"0x00158d0002e8bbbc","type":"EndDevice","model":"MCCGQ01LM","friendly_name":"Terrasse_Sensor","nwkAddr":42418,"manufId":4151,"manufName":"LUMI","powerSource":"Battery","modelId":"lumi.sensor_magnet","hwVersion":2,"swBuildId":"3000-0001","dateCode":"20150424"}]}


Warum hat mein MQTT Port 40826 und 28, ich hatte den mit 1883 erstellt ? Oder ist das normal ?

Oder wäre es allgemein einfach mosquito zu installieren ? Ich hatte vorher den MQTT Broker von OpenHab, da dort ja ein Bug mit MQTT drin ist und daher meine Rollos nicht fahren, bin ich auf FHEM umgestiegen, hierzu hab ich natürlich OH deaktiviert und somit ist mein Broker auch weg.
Base : Intel NUC Debian 9, FHEM aktuell || Zigbee (Coordinator FW Z-Stack 1.2 default Koenkk) || MaxCUL (culfw V 1.67 nanoCUL868) || SIGNALduino 433MHz (V 3.3.2.1-rc8 ) || Shelly s1

Beta-User

Hmm, eigentlich ist das eher eine MQTT-Frage als zigbee (oder evtl. eine USB-Anbindungssache, s.u.). Würde anregen, den Tread nach MQTT zu verschieben (da sind mehr zigbee2mqtt-Nutzer...)

Vorab: an einen auto-update-Mechanismus von zigbee2mqtt glaube ich nicht... (geht vielleicht, aber das wüßtest du, wenn du da was eingerichtet hättest).

Zitat von: D3ltorohd am 27 Juni 2019, 21:02:37
Wenn ich das ganze im Terminal anschaue, hat Zigbee2MQTT eine Verbindung zum Stick und der Kontakt wird auch wunderbar erkannt.
Wie verfolgst du die Verbindung im Terminal?
Insbesondere: Läuft der zigbee2mqtt-Dienst überhaupt?

Meine Vermutung: Da kommt sich was im USB-Bereich in die Quere. Daher: Gibt es weitere USB-Geräte, und wenn ja welche und wie sind die in FHEM und zigbee2mqtt jeweils eingebunden?
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

rudolfkoenig

@D3ltorohd: Ja, so ein Log brauche ich, aber natuerlich fuer den Zeitraum mir dem Problem, und hier sehe ich keins.
40826 ist die Portnummer dieser Verbindung, kommt von TCP/IP.

Übrigens: PUBCOMP koennte auch einfach Teil einer "Muell-Nachricht" sein.
Ich würde Beta-Users Fragen als Nächstes nachgehen, es sei denn, du kannst das Problem reproduzieren, dann bitte es mit dem "verbose 5"-Log protokollieren.

Beta-User

...Nachtrag: eventuell braucht es keine weiteren physischen Geräte an USB, und du mußt auch nichts aktiv gemacht haben: Schau einfach mal nach, ob du eine CUL-Definition hast und stell die ggf. hier mal ein (zusammen mit dem configuration.yaml-Auszug, der die Schnittstelle für das Dongle festlegt).

@Rudi: Wenn es das ist, war autocreate/initialUsbCheck tätig... Steht zwar (präventiv) im Wiki, dass man das abschalten sollte, aber der Zusammenhang wäre m.E. für Einsteiger nicht leicht zu erkennen (was zum ignorieren oder schnellen Vergessen/Wiedereinschalten führt).
Kann ich in dem Fall irgendwas liefern, um derartige Effekte durch autocreate zu vermindern? (CUL und das Dongle klinken sich sich beide als ttyACM ein; ich bräuchte eine meinem (in diesem Bereich eher niedrigen) Niveau angemessene Anleitung, um (z.B. mit screen, am liebsten der seriellen Konsole in der Arduino-IDE)  sende- und empfangsseitig beide Gerätetypen auf verwert-/unterscheidbare Ausgaben im Rahmen von usbscan testen zu können).
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

rudolfkoenig

CUL sendet \n (d.h. NewLine), dann V\n und erwartet als Regexp: ^V .* CU.*
Würde mich wundern, wenn das fuer den Zigbee Stick zutrifft, die konkrete Antwort insteressiert mich aber doch :)

D3ltorohd

Oh je, ich versuche eure Antworten so gut es geht zu beantworten.

Also ich habe 2 Sticks am NUC, den Zigbee Stick CC2531 an ACC 0 richtig ? Und nen Signalduino also NanoCul Stick an USB 0.

Ich logge mich mit Putty ein und gebe systemctl status zigbee2mqtt.service ein, dann kommt folgendes ::


● zigbee2mqtt.service - zigbee2mqtt
   Loaded: loaded (/etc/systemd/system/zigbee2mqtt.service; enabled; vendor pres
   Active: active (running) since Thu 2019-06-27 20:58:41 CEST; 24h ago
Main PID: 1853 (npm)
    Tasks: 23 (limit: 4915)
   CGroup: /system.slice/zigbee2mqtt.service
           ├─1853 npm
           ├─1864 sh -c node index.js
           └─1865 node index.js


Ich stoppe den Service, gehe in den Install Ordner und führe npm start aus, dabei kommt folgendes ::

zigbee2mqtt:info 2019-6-28 9:01:20 PM Logging to directory: '/opt/zigbee2mqtt/data/log/2019-06-28.21-01-20'
  zigbee2mqtt:info 2019-6-28 9:01:21 PM Starting zigbee2mqtt version 1.4.0 (commit #927c4db)
  zigbee2mqtt:info 2019-6-28 9:01:21 PM Starting zigbee-shepherd
  zigbee2mqtt:info 2019-6-28 9:01:23 PM zigbee-shepherd started
  zigbee2mqtt:info 2019-6-28 9:01:23 PM Coordinator firmware version: '20190425'
  zigbee2mqtt:info 2019-6-28 9:01:23 PM Currently 1 devices are joined:
  zigbee2mqtt:info 2019-6-28 9:01:23 PM Terrasse_Sensor (0x00158d0002e8bbbc): MCCGQ01LM - Xiaomi MiJia door & window contact sensor (EndDevice)
  zigbee2mqtt:info 2019-6-28 9:01:23 PM Zigbee: disabling joining new devices.
  zigbee2mqtt:info 2019-6-28 9:01:23 PM Connecting to MQTT server at mqtt://localhost:1883
  zigbee2mqtt:info 2019-6-28 9:01:23 PM zigbee-shepherd ready
  zigbee2mqtt:info 2019-6-28 9:01:23 PM Connected to MQTT server
  zigbee2mqtt:info 2019-6-28 9:01:23 PM MQTT publish: topic 'zigbee2mqtt/bridge/state', payload 'online'
  zigbee2mqtt:info 2019-6-28 9:01:23 PM MQTT publish: topic 'zigbee2mqtt/Terrasse_Sensor', payload '{"contact":true,"linkquality":94,"battery":100,"voltage":3015,"device":{"ieeeAddr":"0x00158d0002e8bbbc","friendlyName":"Terrasse_Sensor","type":"EndDevice","nwkAddr":42418,"manufId":4151,"manufName":"LUMI","powerSource":"Battery","modelId":"lumi.sensor_magnet","hwVersion":2,"swBuildId":"3000-0001","dateCode":"20150424","status":"online"}}'
  zigbee2mqtt:info 2019-6-28 9:01:23 PM MQTT publish: topic 'zigbee2mqtt/bridge/config', payload '{"version":"1.4.0","commit":"927c4db","coordinator":20190425,"log_level":"info","permit_join":false}'


Wenn ich nun die Terrassentür öffne wird das direkt mitgeteilt. Somit gehe ich davon aus das die Verbindung zum Kontakt zum Stick und Stick zum NUC funktioniert.

zigbee2mqtt:info 2019-6-28 9:03:20 PM MQTT publish: topic 'zigbee2mqtt/Terrasse_Sensor', payload '{"contact":false,"linkquality":94,"battery":100,"voltage":3015,"device":{"ieeeAddr":"0x00158d0002e8bbbc","friendlyName":"Terrasse_Sensor","type":"EndDevice","nwkAddr":42418,"manufId":4151,"manufName":"LUMI","powerSource":"Battery","modelId":"lumi.sensor_magnet","hwVersion":2,"swBuildId":"3000-0001","dateCode":"20150424","status":"online"}}'
  zigbee2mqtt:info 2019-6-28 9:03:22 PM MQTT publish: topic 'zigbee2mqtt/Terrasse_Sensor', payload '{"contact":true,"linkquality":99,"battery":100,"voltage":3015,"device":{"ieeeAddr":"0x00158d0002e8bbbc","friendlyName":"Terrasse_Sensor","type":"EndDevice","nwkAddr":42418,"manufId":4151,"manufName":"LUMI","powerSource":"Battery","modelId":"lumi.sensor_magnet","hwVersion":2,"swBuildId":"3000-0001","dateCode":"20150424","status":"online"}}'


Denke das passt soweit ? Braucht ihr meine yaml Config noch ?

Internals:
   Clients    :IT:CUL_TCM97001:SD_RSL:OREGON:CUL_TX:SD_AS:Hideki:SD_WS07:SD_WS09: :SD_WS:RFXX10REC:Dooya:SOMFY:SD_BELL:SD_UT:SD_WS_Maverick:FLAMINGO:CUL_WS:Revolt: :FS10:CUL_FHTTK:Siro:FHT:FS20:CUL_EM:Fernotron:SD_Keeloq:SIGNALduino_un:
   DEF        /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_003V1IRC-if00-port0@57600
   DMSG       P87#8EE840A68000FBD200
   DevState   initialized
   DeviceName /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_003V1IRC-if00-port0@57600
   FD         7
   FUUID      5cc5dfa7-f33f-fc62-55bd-a1d7b2d894c53e6f
   ITClock    250
   LASTDMSG   P87#8EE840A68000FBD200
   LASTDMSGID 87
   MSGCNT     60
   NAME       JarolifCUL
   NR         14
   NR_CMD_LAST_H 7
   PARTIAL   
   RAWMSG     MS;P1=1628;P2=-398;P3=390;P4=-3934;P5=-776;P6=831;P7=-15736;D=34356262623535356235353562356262626235626262626262356235626235356235626262626262626262626262626262353535353562353535356235626235626262626262626267123232323232323232;CP=3;SP=4;R=255;O;s=32;m0;
   RSSI       -74.5
   STATE      opened
   TIME       1561747615
   TYPE       SIGNALduino
   sendworking 0
   version    V 3.3.2.1-rc8 SIGNALduino cc1101 - compiled at Jan 10 2019 20:13:56
   versionProtocols 1.03
   versionmodul v3.4.0_dev_16.03
   DoubleMsgIDs:
   MatchList:
     10:SD_WS07 ^P7#[A-Fa-f0-9]{6}F[A-Fa-f0-9]{2}(#R[A-F0-9][A-F0-9]){0,1}$
     11:SD_WS09 ^P9#F[A-Fa-f0-9]+
     12:SD_WS   ^W\d+x{0,1}#.*
     13:RFXX10REC ^(20|29)[A-Fa-f0-9]+
     14:Dooya   ^P16#[A-Fa-f0-9]+
     15:SOMFY   ^Ys[0-9A-F]+
     16:SD_WS_Maverick ^P47#[A-Fa-f0-9]+
     17:SD_UT   ^P(?:14|29|30|34|46|69|76|81|83|86|90|91|91.1|92|93|95)#.*
     18:FLAMINGO ^P13\.?1?#[A-Fa-f0-9]+
     19:CUL_WS  ^K[A-Fa-f0-9]{5,}
     1:IT       ^i......
     20:Revolt  ^r[A-Fa-f0-9]{22}
     21:FS10    ^P61#[A-F0-9]+
     22:Siro    ^P72#[A-Fa-f0-9]+
     23:FHT     ^81..(04|09|0d)..(0909a001|83098301|c409c401)..
     24:FS20    ^81..(04|0c)..0101a001
     25:CUL_EM  ^E0.................
     26:Fernotron ^P82#.*
     27:SD_BELL ^P(?:15|32|41|42|57|79)#.*
     28:SD_Keeloq ^P(?:87|88)#.*
     2:CUL_TCM97001 ^s[A-Fa-f0-9]+
     3:SD_RSL   ^P1#[A-Fa-f0-9]{8}
     4:OREGON   ^(3[8-9A-F]|[4-6][0-9A-F]|7[0-8]).*
     5:CUL_TX   ^TX..........
     6:SD_AS    ^P2#[A-Fa-f0-9]{7,8}
     7:Hideki   ^P12#75[A-F0-9]+
     9:CUL_FHTTK ^T[A-F0-9]{8}
     X:SIGNALduino_un ^[u]\d+#.*
   QUEUE:
   READINGS:
     2019-05-05 21:13:03   config          MS=1;MU=1;MC=1;Mred=1;Mdebug=1_MScnt=4;MuSplitThresh=8000;MdebFifoLimit=120/140
     2019-06-28 21:04:51   ping            OK
     2019-06-27 20:57:43   state           opened
     2019-06-27 20:57:43   version         V 3.3.2.1-rc8 SIGNALduino cc1101 - compiled at Jan 10 2019 20:13:56
   XMIT_TIME:
     1561739042
     1561739045
     1561739046
     1561739048
     1561739049
     1561739055
     1561739080
   getcmd:
   keepalive:
     ok         1
     retry      0
   mcIdList:
   msIdList:
     87
   muIdList:
Attributes:
   whitelist_IDs 87


Und indem Fall hier doch die yaml Config.

homeassistant: false
permit_join: false
mqtt:
  base_topic: zigbee2mqtt
  server: 'mqtt://localhost:1883'
  user: my_user
  password: my_password
  client_id: MY_CLIENT_ID
  reject_unauthorized: true
  include_device_information: true
serial:
  port: /dev/ttyACM0
  disable_led: false
devices:
  '0x00158d0002e8bbbc':
    friendly_name: Terrasse_Sensor
    retain: false


Ich hoffe das ist das was ihr von mir wolltet  ???

EDIT:: So ich hab jetzt einfach mal wild drauf los gemacht, den MQTT Server in FHEM deinstalliert und den MQTT Broker Mosquitto installiert, den Nuc neu gestartet und sofort war der Stick in FHEM online und ich sehe sofort den State der Tür, auf oder zu !!
Base : Intel NUC Debian 9, FHEM aktuell || Zigbee (Coordinator FW Z-Stack 1.2 default Koenkk) || MaxCUL (culfw V 1.67 nanoCUL868) || SIGNALduino 433MHz (V 3.3.2.1-rc8 ) || Shelly s1

rudolfkoenig

ZitatSo ich hab jetzt einfach mal wild drauf los gemacht, den MQTT Server in FHEM deinstalliert und den MQTT Broker Mosquitto installiert, den Nuc neu gestartet und sofort war der Stick in FHEM online und ich sehe sofort den State der Tür, auf oder zu !!
Ich vermisse mindestens die Definition einer MQTT oder MQTT_CLIENT Instanz.
Oder gabs diese auch vorher?
Wenn ja, dann war das vmtl. die Ursache, da diese sich gegenseitig ausschliessen:
- MQTT2_SERVER oder
- MQTT2_CLIENT + mosquitto oder
- MQTT + mosquitto

Beta-User

Zitat von: rudolfkoenig am 28 Juni 2019, 19:54:46
CUL sendet \n (d.h. NewLine), dann V\n und erwartet als Regexp: ^V .* CU.*
Würde mich wundern, wenn das fuer den Zigbee Stick zutrifft, die konkrete Antwort insteressiert mich aber doch :)
Hmm, also:

Der Zigbee-Stick wirft grundsätzlich erst mal schlicht nichts aus, wenn er neu initialisiert wird, jedenfalls mit "V" sind ihm keine Infos zu entlocken (Gegenprobe mit CUL@Arduino-IDE funktionierte erwartungsgemäß bei niedrigeren Baudraten). ABER: Sendet ein (gespeicherter) "Peer" (z.B. eine angelernte Leuchte) irgendwas, kommen Ausgaben, die ziemlich "Kauderwelschig" sind (ich habe auch hier versch. Baudraten versucht, und eigentlich sollte @115200 passen), es kommt aber immer was in der Art (hier: wenn zwei Tint-Bulbs gemeinsam angeschaltet werden):
Zitat⸮ E⸮;C;CQ⸮ ⸮⸮⸮⸮⸮⸮c⸮ E⸮A A ⸮e⸮⸮⸮⸮⸮⸮\

Vermutlich also keine "USB-Verwirrung".

@D3ltorohd:
Trotzdem solltest du mal nachsehen, ob nicht doch eine weitere CUL-Definition vorhanden ist (nach den Angaben eines anderen Nutzers  hatten wir den Fall nämlich schon mal, dass autocreate beim FHEM-Start bei einem "false positive" einen CUL definiert hatte; kann natürlich auch weg sein, wenn du nicht save genutzt hattest).

Was die yaml angeht, würde ich auch dort empfehlen, die "by-id"-Methode zu nutzen (das geht dort genauso wie in der DEF des nanoCUL).
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

D3ltorohd

Zitat von: Beta-User am 29 Juni 2019, 13:34:47
@D3ltorohd:
Trotzdem solltest du mal nachsehen, ob nicht doch eine weitere CUL-Definition vorhanden ist (nach den Angaben eines anderen Nutzers  hatten wir den Fall nämlich schon mal, dass autocreate beim FHEM-Start bei einem "false positive" einen CUL definiert hatte; kann natürlich auch weg sein, wenn du nicht save genutzt hattest).

Was die yaml angeht, würde ich auch dort empfehlen, die "by-id"-Methode zu nutzen (das geht dort genauso wie in der DEF des nanoCUL).

Nach der Installation von FHEM war das mit das erste, dieses autocreate zu deaktivieren. Das mit dem by-id muss ich mir mal anschauen, du meinst das es beim Cul dann in etwa so aussieht.
/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_003V1IRC-if00-port0@57600

Also ich habe nun 2 Def's die mit MQTT zu tun haben, davor noch eine 3, quasi den MQTT2 Server, den es in FHEM gibt.

den Client


Internals:
   DEF        127.0.0.1:1883
   DeviceName 127.0.0.1:1883
   FD         4
   FUUID      5ccecb03-f33f-fc62-0c80-3a84ef68ae5f8109
   NAME       mqtt
   NOTIFYDEV  global
   NR         20
   NTFY_ORDER 50-mqtt
   PARTIAL   
   STATE      opened
   TYPE       MQTT
   buf       
   msgid      7
   ping_received 1
   timeout    60
   READINGS:
     2019-06-29 16:04:13   connection      active
     2019-06-28 21:16:57   state           opened
   messages:
Attributes:
   room       MQTT


hier noch eins für den Signalduino oder bzw den NanoCUL



Internals:
   DEF        JaroFB
   FUUID      5cceee3b-f33f-fc62-ab7f-f1cd9bc155139f84
   IODev      mqtt
   NAME       mqtt_Bridge_JaroFB
   NOTIFYDEV  JaroFB
   NR         22
   NTFY_ORDER 50-mqtt_Bridge_JaroFB
   STATE      ???
   TYPE       MQTT_BRIDGE
   READINGS:
     2019-06-29 14:21:04   transmission-state outgoing publish sent
   message_ids:
   publishReadings:
     LastAction_Channel_01 /JaroFB/LastAction_Channel_01
     LastAction_Channel_02 /JaroFB/LastAction_Channel_02
     LastAction_Channel_03 /JaroFB/LastAction_Channel_03
     LastAction_Channel_04 /JaroFB/LastAction_Channel_04
     LastAction_Channel_05 /JaroFB/LastAction_Channel_05
     LastAction_Channel_06 /JaroFB/LastAction_Channel_06
     LastAction_Channel_07 /JaroFB/LastAction_Channel_07
     LastAction_Channel_08 /JaroFB/LastAction_Channel_08
     LastAction_Channel_09 /JaroFB/LastAction_Channel_09
     LastAction_Channel_1 /JaroFB/LastAction_Channel_1
     LastAction_Channel_10 /JaroFB/LastAction_Channel_10
     LastAction_Channel_11 /JaroFB/LastAction_Channel_11
     LastAction_Channel_12 /JaroFB/LastAction_Channel_12
     button     /JaroFB/button
     channel    /JaroFB/channel
     channel_control /JaroFB/channel_control
     counter_receive /JaroFB/counter_receive
     counter_send /JaroFB/counter_send
     last_digits /JaroFB/last_digits
     serial_receive /JaroFB/serial_receive
     state      /JaroFB/state
     user_info  /JaroFB/user_info
     user_modus /JaroFB/user_modus
   subscribe:
     /JaroFB/set
   subscribeExpr:
     ^\/JaroFB\/set$
   subscribeQos:
     /JaroFB/set 0
   subscribeSets:
     /JaroFB/set:
       cmd       
       name       
Attributes:
   IODev      mqtt
   publishReading_LastAction_Channel_01 /JaroFB/LastAction_Channel_01
   publishReading_LastAction_Channel_02 /JaroFB/LastAction_Channel_02
   publishReading_LastAction_Channel_03 /JaroFB/LastAction_Channel_03
   publishReading_LastAction_Channel_04 /JaroFB/LastAction_Channel_04
   publishReading_LastAction_Channel_05 /JaroFB/LastAction_Channel_05
   publishReading_LastAction_Channel_06 /JaroFB/LastAction_Channel_06
   publishReading_LastAction_Channel_07 /JaroFB/LastAction_Channel_07
   publishReading_LastAction_Channel_08 /JaroFB/LastAction_Channel_08
   publishReading_LastAction_Channel_09 /JaroFB/LastAction_Channel_09
   publishReading_LastAction_Channel_1 /JaroFB/LastAction_Channel_1
   publishReading_LastAction_Channel_10 /JaroFB/LastAction_Channel_10
   publishReading_LastAction_Channel_11 /JaroFB/LastAction_Channel_11
   publishReading_LastAction_Channel_12 /JaroFB/LastAction_Channel_12
   publishReading_button /JaroFB/button
   publishReading_channel /JaroFB/channel
   publishReading_channel_control /JaroFB/channel_control
   publishReading_counter_receive /JaroFB/counter_receive
   publishReading_counter_send /JaroFB/counter_send
   publishReading_last_digits /JaroFB/last_digits
   publishReading_serial_receive /JaroFB/serial_receive
   publishReading_state /JaroFB/state
   publishReading_user_info /JaroFB/user_info
   publishReading_user_modus /JaroFB/user_modus
   room       MQTT
   subscribeSet /JaroFB/set
Base : Intel NUC Debian 9, FHEM aktuell || Zigbee (Coordinator FW Z-Stack 1.2 default Koenkk) || MaxCUL (culfw V 1.67 nanoCUL868) || SIGNALduino 433MHz (V 3.3.2.1-rc8 ) || Shelly s1

Beta-User

Den nanoCUL hattest du doch "by-id" definiert, wenn ich das richtig im Kopf habe (also so in der Art wie gepostet).

Das solltest du für den zigbee-Stick ähnlich machen, nur eben in der configuration.yaml, hat ja mit FHEM nicht direkt was zu tun.

Zu den MQTT-Devices kann ich nichts sagen, das sind über 00_MQTT.pm eingebundene Dinge, die du da gelistet hast... Das ist was anderes als MQTT2_DEVICE; was aber die MQTT_BRIDGE mit dem Signalduino zu tun haben soll, verstehe ich nicht so recht (aber ich habe die Geräte nicht; ich würde nur nie neu ein MQTT_BRIDGE-Gerät anlegen; das ist m.E. outdated).
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

D3ltorohd

Zitat von: Beta-User am 29 Juni 2019, 16:16:01
Zu den MQTT-Devices kann ich nichts sagen, das sind über 00_MQTT.pm eingebundene Dinge, die du da gelistet hast... Das ist was anderes als MQTT2_DEVICE; was aber die MQTT_BRIDGE mit dem Signalduino zu tun haben soll, verstehe ich nicht so recht (aber ich habe die Geräte nicht; ich würde nur nie neu ein MQTT_BRIDGE-Gerät anlegen; das ist m.E. outdated).

Ursprünglich wollte ich über diese Bridge mit OpenHab 2 kommunizieren, weil ich dort schon alle Rollos angelegt hatte, Rules und das WebInterface, da der Signalduino nur auf FHEM läuft und ich den NanoCul für die Rollos nutze, wollte ich eben per MQTT Befehl die Rollos aus OH steuern. Da OH2 aber Probleme oder Bugs im MQTT2 Protokoll hat, bin ich jetzt erst mal auf FHEM mit ASC umgestiegen, daher ist die Bridge noch vorhanden.
Base : Intel NUC Debian 9, FHEM aktuell || Zigbee (Coordinator FW Z-Stack 1.2 default Koenkk) || MaxCUL (culfw V 1.67 nanoCUL868) || SIGNALduino 433MHz (V 3.3.2.1-rc8 ) || Shelly s1

Beta-User

na wie auch immer...

Nur zur Klarstellung: es gibt kein "MQTT2-Protokoll" auch MQTT2_SERVER nutzt dasselbe Protokoll wie andere MQTT-Geräte auch. Er hat nur nicht die volle Serverfunktionalität (afaik z.B. kein QoS2), sondern ist eher auf FHEM-only Nutzung ausgelegt (da aber einfacher zu handhaben, da man keine weiteren Perl-libs braucht usw.).

Jedenfalls: Wenn du jetzt die zigbee-Teile via zigbee2mqtt nach FHEM bringen willst, hast du zwei Optionen: entweder 00_MQTT.pm als IO + MQTT-Xiaomi-Bridge (oder so ähnlich) als Client-Devices; nicht offiziell hier supportet, aber ein Thread dazu vorhanden), oder du nutzt _zusätzlich_ zu dem, was du hast MQTT2_CLIENT und kannst dann (im Prinzip) die "Praxisbeispiele" im Wiki zur Konfiguration von MQTT2_DEVICE-Geräten (mit attrTemplate) nachvollziehen.
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

D3ltorohd

Verbindung steht doch schon und funktioniert wieder wunderbar. Hab jetzt wie gesagt den mosquitto Server installiert und seither lauft das Zigbee Zeug.

Vielen Dank für alle die Infos, Tipps und Hilfe !!
Base : Intel NUC Debian 9, FHEM aktuell || Zigbee (Coordinator FW Z-Stack 1.2 default Koenkk) || MaxCUL (culfw V 1.67 nanoCUL868) || SIGNALduino 433MHz (V 3.3.2.1-rc8 ) || Shelly s1