Kann auf einmal nichts mehr pairen (Zigbee Stick CC2531)

Begonnen von D3ltorohd, 01 Oktober 2019, 16:47:17

Vorheriges Thema - Nächstes Thema

D3ltorohd

Hallo Com,

ich habe mir die Innr SP 120 gekauft um die Anzahl meiner Zigbee Geräte zu erhöhen, des weiteren soll die Dose als Repeater fungieren. Leider bekomme ich das Teil nicht gepairt. In Fhem ist autocreate active, set 1 pair hab ich am Stick gemacht und danach 5 Sekunden die Taste an der Steckdose gedrückt, aber es passiert rein gar nichts, die Dose ist ca. 1,5 m weg vom Stick.
Kann auch nichts in der Log sehen, da passiert rein gar nichts.

Muss ich noch was beachten, etwas anders machen. Laut Seite wird die Steckdose ja supported.

Grüße,

EDIT:::

ich dachte erst es liegt vllt an der neuen Steckdose von Innr, da ich diese nicht pairen konnte. Also habe ich Aqara Sensoren probiert, auch diese kann ich nicht mehr pairen, obwohl die schon mal gepairt waren. Sogar der, den ich extra als Device entfernt habe um Platz für die Innr zu machen. Ich hatte 15 Aqara Sensoren, die zu pairen hat wunderbar geklappt. Da ich ja dann die neue Steckdose pairen wollte um die Device Anzahl zu erhöhen, habe ich einen Sensor entfern/gelöscht, er steht auch nicht mehr in der config.yaml als Deviceleiche.

Jeder versuch, diesen Sensor oder zwei andere die noch fehlen zu pairen, funktioniert nicht. Ich setzte den Stick in den Pair Modus über FHEMWEB, starte den Pairprozess an den Sensoren und nichts passiert, kein neues Device nix. Autocreate in Fhem ist auch aktiviert.

Wie gesagt das hatte früher wunderbar geklappt. Und die die gepairt sind kommunizieren auch wunderbar mit dem Stick und in FHEM reagiert das Device direkt auf den Zustand der Sensoren, also auf oder zu.

Hatte das schon mal jemand, habt ihr das in den Griff bekommen ? Was kann ich noch tun ?

Habe eine FW von April 2019 drauf, zigbee2mqtt hatte ich dann noch versucht zu aktualisieren auf die Version 1.6.0 . Aber auch danach hat es keine Besserung gebracht. Ach ja, gepaird wird direkt am Stick, um evt. schlechten Empfang aus zu grenzen.
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

Bei mir hat das geklappt. Ich verrate dir aber nicht, warum :-* .

(Oder vielleicht doch, wenn du mir verrätst, über welche Art der Einbindung wir hier grade reden und das übertragbar sein sollte...)

Anmerkung: Bitte denke beim Erstellen deiner Beiträge daran, dass potentielle Helfer nicht "riechen" können, wie dein Umfeld aussieht. Leider sind die letzten deiner Beiträge, die ich "aus dem Augenwinkel" gesehen habe, in diese Richtung wenig erhellend.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

D3ltorohd

Zitat von: Beta-User am 01 Oktober 2019, 17:09:58
Bei mir hat das geklappt. Ich verrate dir aber nicht, warum :-* .

(Oder vielleicht doch, wenn du mir verrätst, über welche Art der Einbindung wir hier grade reden und das übertragbar sein sollte...)

Anmerkung: Bitte denke beim Erstellen deiner Beiträge daran, dass potentielle Helfer nicht "riechen" können, wie dein Umfeld aussieht. Leider sind die letzten deiner Beiträge, die ich "aus dem Augenwinkel" gesehen habe, in diese Richtung wenig erhellend.
h
Sorry, du hast recht. Also ich habe einen Zigbee Stick CC2531 mit der Z-Stack FW von Koenkk als Coordinator drauf, der hängt an meinem NUC, dort läuft Linux. Desweiteren läuft noch zigbee2mqtt. Das Device ist so angelegt.

Zitat

Internals:
   DEF        bridge
   FRIENDLYNAME bridge
   FUUID      5d0e7cfd-f33f-fc62-bdc7-8a67643fbcaf5bec
   IODev      mqtt
   MODEL      bridge
   NAME       Zigbee2MQTT
   NOTIFYDEV  bridge
   NR         38
   SID        bridge
   STATE      online
   TYPE       XiaomiMQTTDevice

Bisher hat es eigentlich wunderbar funktioniert, bin bloß an die Grenze von 15 Geräten gekommen. Daher die Innr Dose, in der Hoffnung, sie als Repeater zu nutzen und um meine Reichweite zu erhöhen.
Dazu hab ich eben das 15. Device gelöscht um Platz zu haben.

Aber mittlerweile hab ich das Gefühl, es liegt am Stick, oder an FHEM ka. Ich kann auch meinen alten Sensor den ich vorher gelöscht habe, nicht wieder anlernen. Der Rest der Sensoren reagiert aber und Sendet den Status sauber an FHEM.

Autocreate kann ja nicht defekt sein ? Auf active steht es. Schon merkwürdig. Habe FHEM restartet, habe das aktuellste Z2M installiert, habe auch das ganze System rebootet, nichts.
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

Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

D3ltorohd

Auf den gewünschten Sensor geklickt und dann unten auf delet device (xxx). Danach hab ich in der config.yamil in zigbee 2mqtt Ordner geschaut ob es dort noch in der Liste auftaucht. Wurde aber sauber entfernt.
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, keine wirkliche Idee.

Spekulation: ich meine mich zu erinnern, dass die Zahl der maximalen Geräte auf dem Stick eine "ca."-Angabe war. Das würde bedeuten, dass der Platz nicht immer gleich ist, den ein einzelnes Gerät beansprucht. Da die innr ein paar Kanäle hat, könnte es sein, dass die "größer" ist als das gelöschte Gerät. Könnte also sein, dass es erst klappt, wenn du noch mehr Platz schaffst. Aber wie gesagt: Spekulativ...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

D3ltorohd

Zitat von: Beta-User am 04 Oktober 2019, 09:51:11
Hmm, keine wirkliche Idee.

Spekulation: ich meine mich zu erinnern, dass die Zahl der maximalen Geräte auf dem Stick eine "ca."-Angabe war. Das würde bedeuten, dass der Platz nicht immer gleich ist, den ein einzelnes Gerät beansprucht. Da die innr ein paar Kanäle hat, könnte es sein, dass die "größer" ist als das gelöschte Gerät. Könnte also sein, dass es erst klappt, wenn du noch mehr Platz schaffst. Aber wie gesagt: Spekulativ...

Hm, ich bekomme aber das extra gelöschte Sensor Device was vorher gepairt war auch nicht mehr angelenrt, hier liegt es vllt gar nicht mal an der Steckdose sondern an was anderem. Ich habe keine Ahnung warum ich nichts mehr pairen kann, auch nicht die Kontakte die schon dran waren. Hab hier noch 3 rumliegen, keins der 3 konnte ich pairen, passieren tut da beim Pairvorgang nichts. Vllt liegt das Problem wirklich an was anderem.
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

Ich kann's dir nicht sagen, was da schief läuft. Jedenfalls wird unter diesem Titel hier tendenziell keiner allgemeine pairing-Probleme mit einem CC2531 vermuten. Vielleicht solltest du das ändern bzw. einen neuen Thread anfangen (ist aber deiner, würde eher den Titel ändern)?

Vielleicht hat jemand einen Tipp, wie man den Speicher auf dem Ti "aufräumt" (Wenn es nicht in der Doku (bei zigbee2mqtt) steht...).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

Byte09

#8
Zitat von: D3ltorohd am 01 Oktober 2019, 22:31:13
Auf den gewünschten Sensor geklickt und dann unten auf delet device (xxx). Danach hab ich in der config.yamil in zigbee 2mqtt Ordner geschaut ob es dort noch in der Liste auftaucht. Wurde aber sauber entfernt.

nicht wirklich gut , da das device dann zwar in fhem gelöscht wird, aber nicht in der config des coordinators wenn ich mich recht erinnere.

damit sollte das device im grunde in fhem auch wieder auftauchen , wenn du in der bridge mal ein set updatedevices ausführst. falls es dann wieder angelegt wird solltest du es mit set device remove löschen , dann wird es auch aus der config des coordinators gelöscht .


wenn das nicht geht solltest du mal im configfile von zigbee2mqtt schauen , ich denke dort steht das device noch drinnen . Findest du unter '/opt/zigbee2mqtt/data' und sieht so aus.
homeassistant: false
permit_join: true
mqtt:
  base_topic: zigbee2mqtt
  server: 'mqtt://localhost'
serial:
  port: /dev/ttyACM0
devices:
  '0x00158d0001ef8849':
    friendly_name: '0x00158d0001ef8849'
    retain: false
  '0x00158d000200b8f0':
    friendly_name: '0x00158d000200b8f0'
    retain: false
  '0x00158d00024e671f':
    friendly_name: '0x00158d00024e671f'
    retain: false
  '0x000b57fffea6de44':
    friendly_name: '0x000b57fffea6de44'
    retain: false
  '0x00158d000200bb9c':
    friendly_name: '0x00158d000200bb9c'
    retain: false
  '0x00158d0002564d59':
    friendly_name: '0x00158d0002564d59'
    retain: false
  '0x00158d0001ef6137':
    friendly_name: '0x00158d0001ef6137'
    retain: false
  '0x00158d00028f76f9':
    friendly_name: '0x00158d00028f76f9'
    retain: false
  '0x00158d00028f71e0':
    friendly_name: '0x00158d00028f71e0'
    retain: false
  '0x00124b0012023468':
    friendly_name: '0x00124b0012023468'
    retain: false
  '0x00124b001202312f':
    friendly_name: '0x00124b001202312f'
    retain: false
  '0x00124b0019366529':
    friendly_name: '0x00124b0019366529'
    retain: false
  '0x000b57fffe9c2c77':
    friendly_name: '0x000b57fffe9c2c77'
    retain: false
  '0x00158d00031b4b20':
    friendly_name: '0x00158d00031b4b20'
    retain: false
  '0x00158d000236a027':
    friendly_name: '0x00158d000236a027'
    retain: false


dort kannst du es manuell löschen. Dazu service stoppen , datei ändern , service neu starten.

ist jetzt alles ein wenig aus der erinnerung , ich habe mich schon einen moment nicht mehr damit beschäftigt , von daher ohne Gewähr  ;)

gruss Byte09

Beta-User

Hmm, ist schwierig zu deuten, was er geschrieben hatte, aber wenn es aus der yaml geflogen ist, scheint das via MQTT auch beim zigbee2mqtt-Dienst angekommen zu sein (über eine spezielle Funktion an diesem xiaomi-MQTT-Dingens, das er zu nutzen scheint...?). So hatte ich jedenfalls die Antwort verstanden.

Aber du hast recht, ein List von dem ehemaligen Device oder der bridge wäre hilfreich gewesen, um Rückfragen zu vermeiden.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

Byte09

Nachtrag:

wenn du alle devices die mal "dran" waren alle nur in fhem gelöscht hast sind sie alle noch in der yaml. Dann wird es vom Platz sicher eng und erklärt warum kein pairing möglich ist, sie sind bereits gepaird... nur nicht mehr in fhem vorhanden.

gruss Byte09

Gesendet von meinem ELE-L29 mit Tapatalk


Beta-User

Zitat von: D3ltorohd am 01 Oktober 2019, 22:31:13
Auf den gewünschten Sensor geklickt und dann unten auf delet device (xxx). Danach hab ich in der config.yamil in zigbee 2mqtt Ordner geschaut ob es dort noch in der Liste auftaucht. Wurde aber sauber entfernt.
Nochmal: Es scheint beim zigbee2mqtt-Dienst angekommen zu sein, wir reden scheinbar nicht über ein einfaches "delete FHEM-Device"...

Aber ob es dann auch an den CC2531 weitergegeben wurde und wie man das feststellen kann, wäre noch so ein Thema, ich hab in dem anderen Thread was von einem verunglückten update-Versuch gelesen.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

Byte09

#12
Zitat von: Beta-User am 04 Oktober 2019, 11:38:18
..
Danach hab ich in der config.yamil in zigbee 2mqtt Ordner geschaut ob es dort noch in der Liste auftaucht. Wurde aber sauber entfernt.
..


sorry, war wohl selektives lesen meinerseits - und damit schlicht überlesen.

kann ich mir aber nicht vorstellen , oder es war in der tat kein delete sondern ein remove.
Sollte dem dem so  sein , sind die angaben hier einfach falsch und das macht hilfe nicht wirklich einfacher

gruss Byte09

ZitatKann auch nichts in der Log sehen, da passiert rein gar nichts.
in welchem Log ?

edit: dann wäre ggf. ein LOG des Dienstes während des pairingversuches hilfreich .

Beta-User

Er nutzt die Einbindung via Xiaomi-irgendwas-Modul. Je nachdem können die Befehle anders heißen. "remove" ist der Begriff, der im zigbee2mqtt-template für MQTT2_DEVICE genutzt wird, aber wie das in dieser anderen Einbindung heißt: k.A..

@D3ltorohd:
Bitte stelle das mal klar und versuche ggf. nochmal, via direktem MQTT-publish (wie genau, ist abhängig vom IO-Modul) zigbee2mqtt zu überreden, das Ding nochmal zu löschen und schau danach mal ins zigbee2mqtt-log.

Muß nach diesem Muster gebaut werden:
BASE_TOPIC/bridge/config/remove $EVTPART1BASE_TOPIC ist vermutlich zigbee2mqtt (list...), $EVTPART1 ist die hex-ID des zu löschenden Devices (falls du die noch irgendwo gesichert hast).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

Byte09

#14
Zitat von: Beta-User am 04 Oktober 2019, 11:49:57
Er nutzt die Einbindung via Xiaomi-irgendwas-Modul. Je nachdem können die Befehle anders heißen. "remove" ist der Begriff, der im zigbee2mqtt-template für MQTT2_DEVICE genutzt wird, aber wie das in dieser anderen Einbindung heißt: k.A.


... ebenso remove device

gruss Byte09


edit: bis hier entsprechende Infos des TE kommen ist wohl alles weitere Spekulation.

- configuration.yaml
- list des XiaomiMQTTDevice
- log des dienstes

und ggf ein älteres log des Dienstes , in dem diese infos noch zu sehen sind ( auch von den gelöschten device):

...
Currently 15 devices are joined:
10/2/2019, 9:09:27 PM - info: 0x00158d0001ef8849 (0x00158d0001ef8849): WXKG11LM - Xiaomi Aqara wireless switch (EndDevice)
10/2/2019, 9:09:27 PM - info: 0x00158d00024e671f (0x00158d00024e671f): RTCGQ11LM - Xiaomi Aqara human body movement and illuminance sensor (EndDevice)
10/2/2019, 9:09:27 PM - info: 0x00158d000200b8f0 (0x00158d000200b8f0): RTCGQ11LM - Xiaomi Aqara human body movement and illuminance sensor (EndDevice)
10/2/2019, 9:09:27 PM - info: 0x00158d00028f76f9 (0x00158d00028f76f9): MFKZQ01LM - Xiaomi Mi/Aqara smart home cube (EndDevice)
10/2/2019, 9:09:27 PM - info: 0x00158d000200bb9c (0x00158d000200bb9c): RTCGQ11LM - Xiaomi Aqara human body movement and illuminance sensor (EndDevice)
10/2/2019, 9:09:27 PM - info: 0x000b57fffea6de44 (0x000b57fffea6de44): E1525 - IKEA TRADFRI motion sensor (EndDevice)
10/2/2019, 9:09:27 PM - info: 0x00158d0002564d59 (0x00158d0002564d59): MFKZQ01LM - Xiaomi Mi/Aqara smart home cube (EndDevice)
10/2/2019, 9:09:27 PM - info: 0x00158d0001ef6137 (0x00158d0001ef6137): WXKG11LM - Xiaomi Aqara wireless switch (EndDevice)
10/2/2019, 9:09:27 PM - info: 0x00158d00028f71e0 (0x00158d00028f71e0): MFKZQ01LM - Xiaomi Mi/Aqara smart home cube (EndDevice)
10/2/2019, 9:09:27 PM - info: 0x00124b0012023468 (0x00124b0012023468): CC2530.ROUTER - Custom devices (DiY) [CC2530 router](http://ptvo.info/cc2530-based-zigbee-coordinator-and-router-112/) (Router)
10/2/2019, 9:09:27 PM - info: 0x00124b001202312f (0x00124b001202312f): CC2530.ROUTER - Custom devices (DiY) [CC2530 router](http://ptvo.info/cc2530-based-zigbee-coordinator-and-router-112/) (Router)
10/2/2019, 9:09:27 PM - info: 0x00124b0019366529 (0x00124b0019366529): CC2530.ROUTER - Custom devices (DiY) [CC2530 router](http://ptvo.info/cc2530-based-zigbee-coordinator-and-router-112/) (Router)
10/2/2019, 9:09:27 PM - info: 0x000b57fffe9c2c77 (0x000b57fffe9c2c77): LED1623G12 - IKEA TRADFRI LED bulb E27 1000 lumen, dimmable, opal white (Router)
10/2/2019, 9:09:27 PM - info: 0x00158d00031b4b20 (0x00158d00031b4b20): RTCGQ11LM - Xiaomi Aqara human body movement and illuminance sensor (EndDevice)
10/2/2019, 9:09:27 PM - info: 0x00158d000236a027 (0x00158d000236a027): RTCGQ11LM - Xiaomi Aqara human body movement and illuminance sensor (EndDevice)
10/2/2019, 9:09:27 PM - warn: `permit_join` set to  `true` in configuration.yaml.
10/2/2019, 9:09:27 PM - warn: Allowing new devices to join.
...