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,
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.
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.
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?
@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.
...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).
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 :)
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 !!
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
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⸮AA⸮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).
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
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).
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.
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.
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 !!