ZigBee Gerät schaltet sich von selber wieder aus - mit ConBee I USB-Stick

[Ruggy]

Ich habe das OS neu aufgesetzt.

Habe versucht, es nach dieser Anleitung (https://heinz-otto.blogspot.com/2022/08/howto-fhem-umzug-von-system-nach-system.html ;und den dort verwiesenen) zu machen.
Es ist wirklich gut geschrieben; bin mir aber nicht sicher, ob ich dann doch alles richtig gemacht habe.

FHEM läuft meiner Meinung nach soweit. Es werden vor allem die vielen o.g. Meldungen in der Logfile nicht mehr angezeigt.
Leider funktioniert aber die Kommunikation mit ConBee (Deconz; Phoscon App) nicht richtig.

Hierzu sind auch Fehler in der Logfile. Hier ein Auszug davon; ab den Fehler bis zum Schluss der Logfile

Code Auswählen Erweitern

2022.10.02 16:22:32 2: HUEBridge_OpenDev: error reading description: http://192.168.1.141/description.xml: Can't connect(1) to http://192.168.1.141:80: IO::Socket::INET: connect: Connection refused
2022.10.02 16:22:32 2: deCONZ: empty answer received for http://192.168.1.141/api/7A75D31B55/config
2022.10.02 16:22:32 2: HUEBridge_OpenDev: got empty config
2022.10.02 16:22:32 1: usb create starting
2022.10.02 16:22:32 3: Probing ZWDongle device /dev/serial1
2022.10.02 16:22:32 3: Probing CUL device /dev/ttyS0
2022.10.02 16:22:32 3: Probing TCM_ESP3 device /dev/ttyUSB0
2022.10.02 16:22:32 3: Probing TCM_ESP2 device /dev/ttyUSB0
2022.10.02 16:22:32 3: Probing FHZ device /dev/ttyUSB0
2022.10.02 16:22:33 3: Probing TRX device /dev/ttyUSB0
2022.10.02 16:22:33 3: Probing ZWDongle device /dev/ttyUSB0
2022.10.02 16:22:33 3: Probing SIGNALDuino device /dev/ttyUSB0
2022.10.02 16:22:34 3: Probing MYSENSORS device /dev/ttyUSB0
2022.10.02 16:22:34 3: Probing ArduCounter device /dev/ttyUSB0
2022.10.02 16:22:34 3: Probing ElsnerWS device /dev/ttyUSB0
2022.10.02 16:22:35 3: Probing FRM device /dev/ttyUSB0
2022.10.02 16:22:40 1: usb create end
2022.10.02 16:22:40 0: Featurelevel: 6.1
2022.10.02 16:22:40 0: Server started with 158 defined entities (fhem.pl:26379/2022-09-03 perl:5.032001 os:linux user:fhem pid:553)
2022.10.02 16:22:40 3: DbLog DbLog - Creating Push-Handle to database SQLite:dbname=/opt/fhem/fhem.db with user
2022.10.02 16:22:40 3: DbLog DbLog - Push-Handle to db SQLite:dbname=/opt/fhem/fhem.db created
2022.10.02 16:22:41 3: CUL_HM set HM_6CE949 statusRequest noArg
2022.10.02 16:22:53 3: ABFALL Muelltonnen - CALENDAR:Muelltonnen_Kalender triggered, updating ABFALL Muelltonnen ...
2022.10.02 16:38:41 3: FHEMWEB WEB CSRF error: csrf_153019247140477 ne csrf_267031206106046 for client WEB_192.168.1.10_50464 / command get deCONZ sensors . For details see the csrfToken FHEMWEB attribute.
2022.10.02 16:38:46 2: AttrTemplates: got 249 entries


Außerdem ist noch folgendes:
"Lastseen" der Sensoren ist vom 25.09.22 und ändert sich nicht.
Das Device deCONZ hat als

Code Auswählen Erweitern

state -> initialized und mit Datum von heute.
Die restlichen Datum sind aber wiederum vom 24. oder 25.09.22

Ich habe jetzt auf die Phoscon App das aktuellste Update darauf gemacht. Konnte zwischendurch nicht mehr auf die Phoscan App zugreifen, was aber mittlerweile wieder funkioniert.

Ich kann mir im Gerät deCONZ die Sensoren mit

Code Auswählen Erweitern

get deCONZ sensors anzeigen lassen.

Habe versuchsweise in der Phoscon App einen Sensor gelöscht und neu angelernt. Dieser wurde dann wieder mit vorherigen Befehl erkannt. Wenn ich jedoch auf den Link von den Sensor klicke (angezeigte "links" bei den Ergebnis von "get ... sensors") springt mir FHEM in einen anderen Temperatursensor.
Jetzt habe ich wieder den Sensor in der Phoscon App gelöscht um ihn neu anzulernen. Das Anlernen funktionierte aber der "Link" wird nicht angezeigt.


Irgendwie stimmt die Verbindung zum ConBee-USB Stick nicht.
Weiter ist mir beim Schreiben jetzt eingefallen, dass ich das Betriebssytem auf einen anderen "Test-Raspberry" mit einer anderen IP-Adresse aufgesetzt habe. Habe dann die SD-Karte in meinen "normalen" Raspberry und dann erst das FHEM Backup eingespielt. Wobei in deCONZ die richtige IP (192.168.1.141) eingetragen ist.
Kann es damit auch zusammen hängen?

Hier noch das List von deCONZ

Code Auswählen Erweitern

Internals:
   DEF        192.168.1.141
   FUUID      5f1bd2bc-f33f-f59f-3727-c2e7350f6569509f
   FVERSION   30_HUEBridge.pm:0.264380/2022-09-22
   INTERVAL   60
   NAME       deCONZ
   NOTIFYDEV  global
   NR         15
   NTFY_ORDER 50-deCONZ
   STATE      initialized
   TYPE       HUEBridge
   host       192.168.1.141
   READINGS:
     2022-09-24 20:52:02   alert           none
     2022-07-02 16:02:29   groups          1/8
     2022-09-25 10:16:51   lastError       resource, /lights/11, not available
     2022-09-24 20:52:02   lastseen        2022-09-24T18:40Z
     2022-09-25 10:13:50   lights          8/16
     2022-09-24 20:52:02   reachable       0
     2022-01-29 17:30:35   rules           0
     2022-01-29 17:30:35   scenes          0
     2022-01-29 17:30:35   schedules       0
     2022-09-25 00:12:53   sensors         30/64
     2022-10-02 16:17:11   state           initialized
   helper:
     count      0
     last_config_timestamp 0
     ignored:
Attributes:
   devStateIcon {(HUEDevice_devStateIcon($name),"toggle")}
   httpUtils  1
   key        7A75D31B55
   room       deCONZ_Geraete
   webCmd     toggle:on:off

Hier ein List als Beispiel von einen Temperatursensor:

Code Auswählen Erweitern

Internals:
   DEF        sensor 17  IODev=deCONZ
   FUUID      5f1bd2bc-f33f-f59f-0f09-8b15fafc524f758d
   FVERSION   31_HUEDevice.pm:0.262040/2022-07-09
   ID         S17
   INTERVAL   
   IODev      deCONZ
   NAME       SCH_EG_TEMPERATUR
   NR         17
   STATE      ???
   TYPE       HUEDevice
   READINGS:
     2022-10-02 16:22:32   IODev           deCONZ
     2022-09-25 16:13:10   battery         78
     2022-09-25 16:13:10   batteryPercent  78
     2018-12-25 11:15:47   dewpoint        4.2
     2018-12-25 11:15:47   humidity        74.35
     2022-09-25 16:13:10   lastseen        2022-09-25T14:13Z
     2022-09-25 16:13:10   reachable       1
     2022-09-25 16:13:10   temperature     14.8
   helper:
     devtype    S
     state     
     update_timeout 1
     configList:
     setList:
Attributes:
   IODev      deCONZ
   event-on-change-reading temperature
   model      lumi.weather
   room       EG_Schlafzimmer

[Ruggy]

Im Gerät deCONZ steht nicht "connected" sondern "toggle" und "on" "off"


Bei einer Erstinstallation müsste ich ja folgenderes eingeben.

Code Auswählen Erweitern

define deConz HUEBridge 192.168.1.141

Code Auswählen Erweitern

attr httpUtils 1

Code Auswählen Erweitern

set deConz active


Kann ich dies nochmal eingeben?
Oder müsste ich alle Geräte (welche über deConz verbunden sind) in FHEM wieder neu verbinden?

[Frank_Huber]

Bei einer Erstinstallation müsste ich ja folgenderes eingeben.

Code Auswählen Erweitern

attr httpUtils 1

sicher dass das nicht

Code Auswählen Erweitern

attr deConz httpUtils 1 sein muss?

[Ruggy]

Ja stimmt, ist ein Schreibfehler und muß

Code Auswählen Erweitern


attr deConz httpUtils 1

heißen.

[Ruggy]

Habe es jetzt mal nur mit

Code Auswählen Erweitern


set deConz active

und in der Phoscon App auf "App verbinden" geklickt.

Die verschiedenen Sensoren haben jetzt das Datum von heute drinnen. Scheint also etwas positives erstmal bewirkt zu haben.

Werde es jetzt mal beobachten.

[Ruggy]

Jetzt wird das Logfile aber leider mit folgenden Einträgen vollbombadiert 

Also das selbe als wie mit dem alten OS.

Hier ein Ausschnitt vom Logfile:

Code Auswählen Erweitern

2022.10.02 20:15:40 5: KEL_LUFTFEUCHTIGKEIT: using offsetUTC 7200 from bridge
2022.10.02 20:15:40 4: KEL_LUFTFEUCHTIGKEIT: ignoring reading reachable with timestamp 2022-10-02 19:55:02, current reading timestamp is 2022-10-02 19:55:02
2022.10.02 20:15:40 4: KEL_LUFTFEUCHTIGKEIT: ignoring reading lastseen with timestamp 2022-10-02 19:55:02, current reading timestamp is 2022-10-02 19:55:02
2022.10.02 20:15:40 4: KEL_LUFTFEUCHTIGKEIT: ignoring reading batteryPercent with timestamp 2022-10-02 19:55:02, current reading timestamp is 2022-10-02 19:55:02
2022.10.02 20:15:40 4: KEL_LUFTFEUCHTIGKEIT: ignoring reading humidity with timestamp 2022-10-02 19:55:02, current reading timestamp is 2022-10-02 19:55:02
2022.10.02 20:15:40 4: KEL_LUFTFEUCHTIGKEIT: ignoring reading temperature with timestamp 2022-10-02 19:55:02, current reading timestamp is 2022-10-02 20:14:44
2022.10.02 20:15:40 4: KEL_LUFTFEUCHTIGKEIT: ignoring reading battery with timestamp 2022-10-02 19:55:02, current reading timestamp is 2022-10-02 19:55:02
2022.10.02 20:15:40 4: parse status message for AUS_LUFTFEUCHTIGKEIT
2022.10.02 20:15:40 5: AUS_LUFTFEUCHTIGKEIT: using offsetUTC 7200 from bridge
2022.10.02 20:15:40 4: AUS_LUFTFEUCHTIGKEIT: ignoring reading humidity with timestamp 2022-10-02 20:11:22, current reading timestamp is 2022-10-02 20:11:22
2022.10.02 20:15:40 4: AUS_LUFTFEUCHTIGKEIT: ignoring reading batteryPercent with timestamp 2022-10-02 20:11:22, current reading timestamp is 2022-10-02 20:11:22
2022.10.02 20:15:40 4: AUS_LUFTFEUCHTIGKEIT: ignoring reading lastseen with timestamp 2022-10-02 20:11:22, current reading timestamp is 2022-10-02 20:11:22
2022.10.02 20:15:40 4: AUS_LUFTFEUCHTIGKEIT: ignoring reading reachable with timestamp 2022-10-02 20:11:22, current reading timestamp is 2022-10-02 20:11:22
2022.10.02 20:15:40 4: AUS_LUFTFEUCHTIGKEIT: ignoring reading battery with timestamp 2022-10-02 20:11:22, current reading timestamp is 2022-10-02 20:11:22
2022.10.02 20:15:40 4: parse status message for HUEDevice7
2022.10.02 20:15:40 4: parse status message for HUEDevice18
2022.10.02 20:15:40 4: parse status message for HUEDevice9
2022.10.02 20:15:42 4: parse status message for HUEDevice9
2022.10.02 20:16:07 4: parse status message for HUEDevice9
2022.10.02 20:16:07 4: HUEDevice9: bridge has events api: 1
2022.10.02 20:16:14 4: parse status message for KEL_LUFTFEUCHTIGKEIT
2022.10.02 20:16:14 4: KEL_LUFTFEUCHTIGKEIT: bridge has events api: 1
2022.10.02 20:16:14 4: parse status message for KEL_LUFTFEUCHTIGKEIT
2022.10.02 20:16:14 5: KEL_LUFTFEUCHTIGKEIT: using offsetUTC 7200 from bridge
2022.10.02 20:16:16 4: parse status message for HUEDevice9
2022.10.02 20:16:37 4: parse status message for HUEDevice18
2022.10.02 20:16:40 4: parse status message for KEL_LUFTFEUCHTIGKEIT
2022.10.02 20:16:40 5: KEL_LUFTFEUCHTIGKEIT: using offsetUTC 7200 from bridge
2022.10.02 20:16:40 4: KEL_LUFTFEUCHTIGKEIT: ignoring reading humidity with timestamp 2022-10-02 20:16:14, current reading timestamp is 2022-10-02 20:16:14
2022.10.02 20:16:40 4: KEL_LUFTFEUCHTIGKEIT: ignoring reading temperature with timestamp 2022-10-02 20:16:14, current reading timestamp is 2022-10-02 20:16:14
2022.10.02 20:16:40 4: parse status message for AUS_LUFTFEUCHTIGKEIT
2022.10.02 20:16:40 5: AUS_LUFTFEUCHTIGKEIT: using offsetUTC 7200 from bridge
2022.10.02 20:16:40 4: AUS_LUFTFEUCHTIGKEIT: ignoring reading battery with timestamp 2022-10-02 20:11:22, current reading timestamp is 2022-10-02 20:11:22
2022.10.02 20:16:40 4: AUS_LUFTFEUCHTIGKEIT: ignoring reading lastseen with timestamp 2022-10-02 20:11:22, current reading timestamp is 2022-10-02 20:11:22
2022.10.02 20:16:40 4: AUS_LUFTFEUCHTIGKEIT: ignoring reading reachable with timestamp 2022-10-02 20:11:22, current reading timestamp is 2022-10-02 20:11:22
2022.10.02 20:16:40 4: AUS_LUFTFEUCHTIGKEIT: ignoring reading humidity with timestamp 2022-10-02 20:11:22, current reading timestamp is 2022-10-02 20:11:22
2022.10.02 20:16:40 4: AUS_LUFTFEUCHTIGKEIT: ignoring reading batteryPercent with timestamp 2022-10-02 20:11:22, current reading timestamp is 2022-10-02 20:11:22
2022.10.02 20:16:40 4: parse status message for HUEDevice7
2022.10.02 20:16:40 4: parse status message for HUEDevice9
2022.10.02 20:16:40 4: parse status message for HUEDevice18
2022.10.02 20:16:41 4: parse status message for HUEDevice9
2022.10.02 20:17:40 4: parse status message for AUS_LUFTFEUCHTIGKEIT
2022.10.02 20:17:40 5: AUS_LUFTFEUCHTIGKEIT: using offsetUTC 7200 from bridge
2022.10.02 20:17:40 4: AUS_LUFTFEUCHTIGKEIT: ignoring reading battery with timestamp 2022-10-02 20:11:22, current reading timestamp is 2022-10-02 20:11:22
2022.10.02 20:17:40 4: AUS_LUFTFEUCHTIGKEIT: ignoring reading reachable with timestamp 2022-10-02 20:11:22, current reading timestamp is 2022-10-02 20:11:22
2022.10.02 20:17:40 4: AUS_LUFTFEUCHTIGKEIT: ignoring reading lastseen with timestamp 2022-10-02 20:11:22, current reading timestamp is 2022-10-02 20:11:22
2022.10.02 20:17:40 4: AUS_LUFTFEUCHTIGKEIT: ignoring reading batteryPercent with timestamp 2022-10-02 20:11:22, current reading timestamp is 2022-10-02 20:11:22
2022.10.02 20:17:40 4: AUS_LUFTFEUCHTIGKEIT: ignoring reading humidity with timestamp 2022-10-02 20:11:22, current reading timestamp is 2022-10-02 20:11:22
2022.10.02 20:17:40 4: parse status message for KEL_LUFTFEUCHTIGKEIT

[MadMax-FHEM]

Welchen verbose Level hast du eingestellt?
Sind doch "debug" Meldungen auf Level 4 bzw. 5.

Gruß, Joachim

[Ruggy]

In "global" ist verbose 3

im KEL_LUFTFEUCHTIGKEIT ist verbose 5;

Habe noch von drei weiteren Geräten verbose auf 5 gesetzt. Dies habe ich aufgrund dieses Threads zur Fehlersuche (Seite 1) gemacht. Das wegen KEL_LUFTFEUCHTIGKEIT weiß ich jetzt gar nicht wann ich das gemacht habe.

Soll diese Attributes wieder löschen?
Ist das bzgl. dem timestamp dann keine Fehler?

[MadMax-FHEM]

https://wiki.fhem.de/wiki/Verbose

Ich weiß nicht was du meinst...

Zur Fehlersuche eben verbose anpassen, dann wird nat. mehr geloggt...

Wenn das nicht hilft halt verbose wieder zurückstellen (oder Attribut löschen), sonst wird nat. weiterhin mehr geloggt...

Gruß, Joachim

[Ruggy]

Das ursprünglicht Problem und der Grund für diesen Thread war folgendes.
Ich kopiere die Beschreibung des seltsamen Verhaltens nochmal hier her, was der Grund für den Thread war. Ich dachte es hängt irgendwie mit dem "at" zusammen. Die Lists der Geräte würden sich in meinen 1. Beitrag befinden.

Leider gibt es immer noch das "Phänomen", dass sich die Steckdose Osram Smart + nach ca. 30 Sekunden automatisch wieder ausschaltet.
Ich habe es mit einer andern Smart+ versucht, da war es das selbe.


Wenn ich direkt im Device (HUEDevice9) die Smart+ einschalte bleibt sie eingeschalten.
Wenn ich sie jedoch über den Dummy (mit einen DOIF für Einschalten und einen DOIF für Ausschalten) einschalte, schaltet sie sich ca. 8 Sekunden aus, nachdem das DOIF für Einschalten abgearbeitet wurde.

Folgende Devices habe ich:
HUEDevice9 = Smart+ (Steckdose mit Lüfter; derzeit habe ich zum Testen den Lüfter nicht angesteckt)
HUEDevice18 = Relaist für Lüfterklappe öffnen (Xiaomi Doppelrelais)
HUEDevice7 = Relais für Lüfterklappe schließen (Xiaomi Doppelrelais)

So ist der Ablauf:

Ich klicke beim Dummy auf "on"
-> Relais für Lüfterklappe schaltet sofort ein (HUEDevice18)
-> nach 17 Sekunden Relais für Lüfterklappe schaltet aus (HUEDevice18)
-> nach ca. 2 Sekunden Lüfter (HUEDevice9) schaltet ein.
---soweit würde es passen


...aber nach ein paar Sekunden (Dauer ist unterschiedlich; einmal nach 8, dann nach 16, dann nach 40 Sekunden) schaltet sich die Smart+ (HUEDevice9) von selber aus.

An was kann das liegen?

Leider ist das Verhalten unverändert, obwohl ich jetzt ein aktuelles OS darauf habe.

Im Logfile wird es so angezeigt. Ganz genau kann ich es nicht feststellen, wann ich auf "on" im Dummy geklickt habe, weil die "parse status message for..." geloggt werden, ohne dass ich etwas klicke.

[Ruggy]

Hier wäre noch das DOIF fürs einschalten.

Code Auswählen Erweitern

defmod KELLERLUEFTER_MIT_KLAPPEN_EINSCHALTEN_doif DOIF ([Kellerluefter_mit_Klappen:"on"]) (set HUEDevice18 on-for-timer 17) (set HUEDevice9 on)
attr KELLERLUEFTER_MIT_KLAPPEN_EINSCHALTEN_doif room Kellerlüftung
attr KELLERLUEFTER_MIT_KLAPPEN_EINSCHALTEN_doif wait 0,20

[Beta-User]

deconz hast du auch aktualisiert?

Und mach mal aus den HUE-Dimmern ein/aus-Typen. Da verrutscht manchmal was....

[Ruggy]

deconz hätte ich aktualisiert:
Ver. 2.18.02 / 19.09.22
Firmware 26400500

Und mach mal aus den HUE-Dimmern ein/aus-Typen. Da verrutscht manchmal was....

Meinst Du aus dem

Code Auswählen Erweitern

attr HUEDevice7 WebCmd pct:toggle:on:off

ein

Code Auswählen Erweitern

attr HUEDevice7 WebCmd on:off

reicht das dafür?

[Ruggy]

Habe die drei Geräte auf on:off geändert.
Leider ist das Verhalten immer noch unverändert.


Wobei ja alles, vor dem Update vor ca. einer Woche, alles genauso funktioniert hat; auch mit den Dimmern.

[Beta-User]

Nicht der "Anstrich" ist das Problem, sondern der Inhalt (subType)...