Hallo,
habe leider in der Suche und durch Lesen von vielen Foreneinträgen weder mein Problem noch die Lösung dafür gefunden. Auch ist es wohl kein eigentliches FHEM-Problem. Da ich aber nicht mehr weiter weiß, dachte ich, ich schreibe mal einen Eintrag, in der Hoffnung, dass jemand vielleicht eine Idee hat.
Verwende FHEM schon seit Jahren erfolgreich und stabil - das ist wirklich das Beste an FHEM :D - auf einem raspi 3 mit HM-MOD-RPI-PCB. Möchte nun auch gerne noch auf Zigbee erweitern und habe mir dafür den Conbee II besorgt.
Diesen USB-Stick habe ich nach Anleitung installiert. Er läuft auch und findet Hue-Lampen und XIAOMI-Sensoren, sowohl in deCONZ, als auch in Phoscon. Den Port habe ich auf 8091 geändert.
Unter der IP des raspi3 und des Ports konnte ich es auch erfolgreich in FHEM einbinden und kann dadurch über Alexa auch die HUE-Lampen steuern :), oder in FHEM die XIAOMI-Sensoren loggen.
Aber, das ganze funktioniert nur, so lange ich deCONZ explizit aufrufe und als GUI laufen lasse, also
/usr/bin/deCONZ --http-port=8091
So bald ich aber deCONZ als Dienst starte, also
sudo systemctl start deconz
verliere ich in FHEM die Verbindung zu meinem HM-MOD-RPI-PCB, sprich myHmUART:disconnected = 1!
D.h. deCONZ als Dienst belegt, oder schaltet ab(?) den UART, im Gegensatz zu deCONZ als GUI!? :(
Für mich sieht bei den Schnittstellen aber alles gut aus:
pi@raspberrypi:~ $ ls -l /dev/serial*
lrwxrwxrwx 1 root root 7 Dec 1 17:05 /dev/serial0 -> ttyAMA0
lrwxrwxrwx 1 root root 5 Dec 1 17:05 /dev/serial1 -> ttyS0
und
pi@raspberrypi:~ $ ls -l /dev/serial/by-id/
total 0
lrwxrwxrwx 1 root root 13 Dec 3 18:58 usb-dresden_elektronik_ingenieurtechnik_GmbH_ConBee_II_DE2225162-if00 -> ../../ttyACM0
lrwxrwxrwx 1 root root 13 Dec 1 17:05 usb-SHK_NANO_CUL_868-if00-port0 -> ../../ttyUSB0
Wie gesagt, ist wohl kein eigentliches FHEM-Thema, aber vielleicht kann mir ja jemand einen Tip geben.
Vielen Dank schon mal im Voraus!
Vorab mal: Willkommen hier im Forum :) .
1. Idee: startet denn auch die minimal-Version mit demselben HTTP-Port? Was steht dazu in der service-Datei?
Guten Morgen,
hast du den Dienst "deconz-gui" explizit gestoppt, bevor du "deconz" gestartet hast? Je nach Installation kann es sein, dass deconz-gui automatisch läuft (Siehe Doku (https://github.com/dresden-elektronik/deconz-rest-plugin/blob/master/README.md#headless-support-for-linux)). Ist nur ein Schuss ins Blaue, ob das mit deinem Problem zusammenhängen kann, überblicke ich nicht, aber das hat mir anfangs auch Kopfzerbrechen bereitet, bis ich kapiert habe, dass das zwei verschiedene Dienste sind.
2. Idee: "GUI" klingt auch verdächtig nach Modemmanager. Vielleicht spuckt der dazwischen? (OT-Hinweis: Server und GUI = Pfui! Nicht nur meine Meinung...)
Zitat von: Beta-User am 04 Dezember 2020, 07:39:58
Vorab mal: Willkommen hier im Forum :) .
1. Idee: startet denn auch die minimal-Version mit demselben HTTP-Port? Was steht dazu in der service-Datei?
Ich denke auch, dass das erst mal geklärt/verifiziert werden sollte...
War auch mein erster Gedanke:
bei manuellem Start wird ja explizit der Port 8091 mitgegeben (und damit versucht sich dann das HUEBridge-Device auch zu verbinden)
bei Start als Service wird (verm.) der Standardport (80) genommen (wenn nicht eben explizit im Start-Script oder anderer Konfiguration eingestellt)
Beim Standardport können dann 2 Probleme auftreten: deCONZ startet gar nicht -> Konflikt mit Apache (oder Apache startet nicht / je nachdem wer "zuerst kommt" ;) )...
UND: das HUEBridge-Device "findet" natürlich deCONZ nicht unter Port 8091...
Gruß, Joachim
Vielen Dank, erstmal für den Willkommensgruß! Hatte bisher schon viel im Forum gelesen, aber noch nie selbst was geschrieben.
Und vor allem: Vielen Dank für die sehr schnellen Antworten! :D
Zum Problem:
@Beta-User und MadMax-FHEM:
Ja, der Port ist auch bei deconz als Dienst von mir umgestellt:
pi@raspberrypi:~ $ sudo systemctl start deconz
pi@raspberrypi:~ $ sudo systemctl status deconz
● deconz.service - deCONZ: ZigBee gateway -- REST API
Loaded: loaded (/lib/systemd/system/deconz.service; enabled)
Active: active (running) since Fri 2020-12-04 10:30:49 CET; 2s ago
Main PID: 7801 (deCONZ)
CGroup: /system.slice/deconz.service
└─7801 /usr/bin/deCONZ -platform minimal --http-port=8091
Dec 04 10:30:49 raspberrypi systemd[1]: Starting deCONZ: ZigBee gateway -- REST API...
Dec 04 10:30:49 raspberrypi systemd[1]: Started deCONZ: ZigBee gateway -- REST API.
Dec 04 10:30:51 raspberrypi deCONZ[7801]: This plugin does not support propagateSizeHints()
Dec 04 10:30:51 raspberrypi deCONZ[7801]: This plugin does not support propagateSizeHints()
Es ist ja auch so, dass FHEM bei beiden deconz auf Conbee zugreifen kann, aber HM-MOD-RPI-PCB bei der Minimalversion nicht mehr läuft, bzw. der Zugriff seitens FHEM darauf nicht mehr geht.
Und dieser Zugriff auf HM-MOD läuft ja direkt über UART, sprich ist in FHEM definiert als /dev/ttyAMA0.
@ Darkwing Duck
Ja, deconz als GUI läuft definitiv nicht:
pi@raspberrypi:~ $ ps -aux | grep deconz
pi 32566 0.0 0.2 4272 2020 pts/0 S+ 10:43 0:00 grep --color=auto deconz
Das was auch nach einem Stop des deCONZ Dienstes noch läuft ist:
pi@raspberrypi:~ $ ps -aux | grep deC
root 458 10.9 9.9 153904 94196 ? Ss Dec01 431:21 /bin/bash /usr/bin/deCONZ-WIFI2.sh
root 470 0.0 0.3 6084 3748 ? Ss Dec01 3:09 /bin/bash /usr/bin/deCONZ-update2.sh
root 32687 0.0 9.7 153904 92528 ? S 10:43 0:00 /bin/bash /usr/bin/deCONZ-WIFI2.sh
pi 32691 0.0 0.1 4276 1852 pts/0 R+ 10:43 0:00 grep --color=auto deC
Damit geht aber der Zugriff auf HM-MOD...
@Beta-User:
Ja, klar, auf dem kleinen raspi läuft normalerweise keine GUI-Ausgabe. Der steht auch ohne Monitor auf dem Spitzboden. Für die Einrichtung des Conbee hatte ich aber deCONZ gestartet und die Fenster-Anzeige auf meinen Windows-Rechner umgeleitet (putty und Xming).
So sieht übrigens das ps aus, wenn deCONZ als GUI läuft:
pi@raspberrypi:~ $ ps -aux | grep deC
root 458 10.9 9.9 154300 94424 ? Ss Dec01 433:14 /bin/bash /usr/bin/deCONZ-WIFI2.sh
root 470 0.0 0.3 6088 3752 ? Ss Dec01 3:10 /bin/bash /usr/bin/deCONZ-update2.sh
pi 23171 8.7 4.1 130964 39284 pts/0 Sl 10:56 0:02 /usr/bin/deCONZ --http-port=8091
pi 24087 0.0 0.2 4276 2016 pts/0 S+ 10:56 0:00 grep --color=auto deC
Hi,
offenbar zieht der deconz doch die Schnittstelle weg? Weil der prinzipiell auch mit der UART könnte?
So ähnlich wie hier? https://github.com/dresden-elektronik/deconz-rest-plugin/issues/979
Also dem Dienst explizit den Stick angeben?
Gruß Otto
@Otto:
Ich denke der Gedanke kann stimmen!
Denn, wenn man deCONZ als GUI startet, kommt im Fenster als erstes die Auswahl, ob man sich zum ConBee (=USB) oder zum RaspBee (=UART-Modul) verbinden möchte.
Da stellt sich doch die Frage, woher weiß deCONZ als Dienst, was es ansprechen soll?
Bin schon am suchen in den /lib/systemd/system/deconz* Dateien...
Na steht doch in meinem Link in der Art
ExecStart=/usr/bin/deCONZ -platform minimal --http-port=80 --dev=/dev/serial/by-id/usb-FTDI_FT230X_Basic_UART_aaabbbcccddd-if00-port0
Du musst am besten eine ordentliche service Datei anlegen Beispiel https://wiki.fhem.de/wiki/Fhem.service_(systemd_unit_file)
Ich glaube mit sudo systemctl edit deCONZ kannst Du da sogar direkt eine Kopie erstellen - bin nicht mehr ganz sicher.
Gruß Otto
@Otto
Ja, genau, bis auf "--dev ..." hatte ich die /lib/systemd/system/deconz.service auch konfiguriert:
pi@raspberrypi:~ $ more /lib/systemd/system/deconz.service
[Unit]
Description=deCONZ: ZigBee gateway -- REST API
Wants=deconz-init.service deconz-update.service
StartLimitIntervalSec=0
[Service]
User=1000
ExecStart=/usr/bin/deCONZ -platform minimal --http-port=8091
Restart=on-failure
RestartSec=30
AmbientCapabilities=CAP_NET_BIND_SERVICE CAP_KILL CAP_SYS_BOOT CAP_SYS_TIME
[Install]
WantedBy=multi-user.target
Nach einiger Sucherei habe ich jetzt endlich die Optionen von deCONZ gefunden: https://github.com/dresden-elektronik/deconz-rest-plugin/wiki/deCONZ-command-line-parameters (https://github.com/dresden-elektronik/deconz-rest-plugin/wiki/deCONZ-command-line-parameters)
Diese habe ich dann systematisch durchprobiert und festgestellt, dass folgendes wunderbar funktioniert:
pi@raspberrypi:~ $ /usr/bin/deCONZ --dev=/dev/ttyACM0 --auto-connect=1 --http-port=8091
Damit startet deCONZ im GUI-mode und verbindet sich direkt über ttyACM0 mit dem USB-Stick. In FHEM kann ich weiterhin alle Homematic-Geräte per HM-MOD steuern und dann auch die Zigbee-Geräte.
Aber, so bald ich deCONZ headless starten lassen will und dafür die Option "-platform minimal" zusätzlich angebe, funktionieren weder der USB-Stick noch der HM-MOD. Dabei ist es auch egal, ob ich deCONZ über die Commandline starte oder per systemd.
Für mich sieht es zur Zeit stark nach einem Bug in deCONZ aus. Dazu passen könnte auch die erst kürzlich, 12.11.20, vorgenommene Änderung in der Release v2.5.87: "Improve support for stable and dynamic device paths like /dev/ttyACMx and /dev/serial/by-id/ in deCONZ and GCFFlasher to prevent errors on USB re-enumeration."
Außerdem bekomme ich im headless noch eine seltsame Fehlermeldung:
"This plugin does not support propagateSizeHints()"
Werde dann mal versuchen, jemanden für deConz zu erreichen...
Idee: Du hast -platform minimal an erster Stelle der Parameter gelassen?
Nur als Hinweis: Eigentlich sollten die von der Installation gelieferten Unitfiles in /lib/systemd/system im Original bleiben.
Der vom System bevorzugte Weg wäre systemctl edit <unitname> der erzeugt einen Pfad in /etc/systemd/system und eine Datei override.conf unterhalb des neuen Pfades. Dort schreibt man nur die Änderungen gegenüber dem Original rein.
Oder man macht eine Kopie vom Original und editiert diese ... Es gibt dazu gute Beschreibungen.
ansonsten kann ich Dir wohl nicht weiter helfen, ich habe diese Schnittstelle nicht
Ich hatte früher auch das Problem, so dass ich sogar deconz in docker genutzt hatte. Jetzt geht es auch ohne docker.
Zuhause schaue ich nach, wie deconz bei mir jetzt gestartet wird. Habe gerade keinen Zugriff auf mein System.
@Otto
Ja, tatsächlich habe ich die Optionen auch permutiert. Und es gibt anscheinend eine Abhängigkeit von der Position- einmal gab's sogar einen Segmmentation Fault! :o
Vielen Dank für Deine Hilfe! :)
@jhohmann
Das wäre natürlich super!
Benutzt du Conbee oder Conbee II?
Conbee ii, meine ich mich zu erinnern :)
So, bin zuhause und kann nachschauen:
Ich editiere die Services, an denen ich Veränderungen vornehmen will, immer mit folgendem Kommando (hier deconz als Beispiel):
systemctl edit --full deconz
Damit wird automatisch beim ersten Aufruf eine Kopie angelegt und die Änderungen werden auch automatisch nach dem Speichern refreshed, also der wenigste Aufwand.
Und hier der Inhalt von meinem deconz.service:
[Unit]
Description=deCONZ: ZigBee gateway -- REST API
Wants=deconz-init.service deconz-update.service
[Service]
User=fhem
ExecStartPre=/bin/sleep 30
ExecStart=/usr/bin/deCONZ -platform minimal --http-port=8880 --ws-port=8887 --dev=/dev/serial/by-id/usb-dresden_elektronik_ingenieurtechnik_GmbH_ConBee_II_DE2197709-if00
Restart=on-failure
StartLimitIntervalSec=0
RestartSec=30
AmbientCapabilities=CAP_NET_BIND_SERVICE CAP_KILL CAP_SYS_BOOT CAP_SYS_TIME
[Install]
WantedBy=multi-user.target
Die Ports muss du für dich anpassen.
Wofür das AmbientCapabilities steht, kann ich nicht mehr sagen. Vermutlich war das bereits so drin.
@jhohmann
Vielen Dank für die Mühe! :D
Die Optionen im deconz.service passen soweit. Leider findet deconz nur im GUI-mode den Conbee. So bald ich die Option "-platform minimal" setze, findet es den USB-Stick nicht mehr.
Das sehe ich zum einen im Phoscon und zum anderen in den logs im Debug-Mode von deconz.
Könntest Du mir noch den Gefallen tun, und mal schauen welche deconz-Version und welche Firmware-Version Du hast?
Sieht man direkt im Phoscon.
Ich glaube im Moment, dass in der deconz-Release im November sich ein Fehler eingeschlichen hat, als sie "Improve support for stable and dynamic device paths like /dev/ttyACMx and /dev/serial/by-id/ in deCONZ and GCFFlasher to prevent errors on USB re-enumeration." einbauten.
Eventuell mal Dresden Elektronik anschreiben.
Deren Support ist in der Regel echt gut.
Gruß, Joachim
@MadMax-FHEM
Ja, eine E-Mail hatte ich Ihnen bereits geschrieben - aber leider bisher keine Antwort erhalten. :(
Zusätzlich habe ich jetzt versucht Kontakt über den discord-Kanal herzustellen.
https://discord.com/channels/494922323518947329/543512014320828416 (https://discord.com/channels/494922323518947329/543512014320828416)
Habe auch schon erste Antworten, aber noch nichts brauchbares...
Danke, für den Tip! :)
Hier meine aktuelle Version, wobei inzwischen einige Updates eingespielt worden sind.
Version 2.05.88 / 15.10.2020
Firmware 26660700
Früher habe ich beim Login in den deconz-Webanwendung auch zwei Einstiege gesehen, jetzt nur noch einen.
Was eventuell hilft: Mein deconz startet vor FHEM. Eventuell ist es auch ein Reihenfolgeproblem?
Zitat von: topcrown am 07 Dezember 2020, 09:50:09
@MadMax-FHEM
Ja, eine E-Mail hatte ich Ihnen bereits geschrieben - aber leider bisher keine Antwort erhalten. :(
Hmm, eigentlich haben die schon immer recht bald Rückmeldung gegeben...
Gruß, Joachim
So, heute habe ich (endlich) Hilfe im discord channel bekommen.
Der Moderator (!) hatte die Idee, einfach mal zwei Minus vor die Option platform zu setzen, also "
--platform minimal".
Und siehe da, es funktioniert! :)
Anscheinend haben sie in einer der letzten Releases etwas aufgeäumt - alle anderen Optionen haben ja auch zwei Minus. (Warum eigentlich zwei?)
Leider sagt halt die offizielle Beschreibung der Optionen explizit etwas anderes:
ZitatPlease take note, it is invoked with only one dash
und deCONZ beschwert sich auch nicht, wenn man es nur mit einem aufruft... >:(
Also, mein Aufruf in deconz.service lautet nun
ExecStart=/usr/bin/deCONZ --platform minimal --auto-connect=1 --http-port=8880 --ws-port=8887 --dev=/dev/serial/by-id/usb-dresden_elektronik_ingenieurtechnik_GmbH_ConBee_II_DE2225162-if00Vielen Dank noch mal an alle, die versucht haben mir zu helfen! Große Klasse hier im Forum! :D
Grüße,
Thilo
Hallo Thilo,
und ich behaupte immer die offizielle Doku muss doch stimmen :o
Warum zwei? Naja ich denke es hat sich einfach eingebürgert die "langen" Optionen mit zwei -- zu starten die Kurzformen mit einem -.
--help
-h
Gruß Otto
Hallo Otto,
ja klar, kann so gemeint gewesen sein mit langen und kurzen Optionen. Und bis vor kurzem fand man "platform" noch kurz... ;D
Inzwischen wurde auch die offizielle Doku unter https://github.com/dresden-elektronik/deconz-rest-plugin/wiki/deCONZ-command-line-parameters (https://github.com/dresden-elektronik/deconz-rest-plugin/wiki/deCONZ-command-line-parameters) angepasst:
Zitatplatform minimal
In case you want to start headless, use this parameter. In case you want to have access to deCONZ' GUI, just leave this parameter out.
Example: /usr/bin/deCONZ --platform minimal --auto-connect=1
War dann echt schnell geändert.
Sie haben sich auch explizit bei mir bedankt. 8)
Grüße,
Thilo
Achtung ich bin ein Noob.
Ich habe auch Probleme mit dem ConBeeII und dem HM-MOD-RPI-PCB.
Ich bin nun durch den Beitrag und habe /lib/systemd/system/deconz.service
angepasst.
Leider funktioniert der RPI-PCB nun gar nicht mehr, dafür läuft der ConBee stabiler.
ständig connect, disconnect, init
Ich habe den RPI-PCP mit /dev/ttyAMA0@115200 eingebunden. Würde das auch mit "by-id" gehen ?
Wenn ja wie ?
Den Conbee stick habe ich ganz leicht finden können, leider taucht das RPI-PCB nicht auf.
@kiter1988
Es geht auf jeden Fall mit by-id.
Schau mal in meinen letzten Code der deconz.service. Der ist auch mit id und so funktioniert es.
ExecStart=/usr/bin/deCONZ --platform minimal --auto-connect=1 --http-port=8880 --ws-port=8887 --dev=/dev/serial/by-id/usb-dresden_elektronik_ingenieurtechnik_GmbH_ConBee_II_DE2225162-if00
Ich glaube meine ganze Misere fing mit gar keiner, bzw. Angabe von tty an.
Das mit den ständigen, erfolglosen Neuverbindungsversuchen hatte ich auch.
Grüße,
Thilo
Was hat die Einbindung des HM-MOD-RPI-PCB in das Modul HMUARTLGW mit der Einbindung des ConBeeII in den deconz.service zu tun?
Der deconz.service muss so konfiguriert sein dass es er nur die entsprechende Schnittstelle verwendet und /dev/ttyAMA0 in Ruhe lässt.
HMUARTLGW bindet das Modul normal über /dev/ttyAMA0 ein - da dies keine USB Schnittstelle ist, spielt hier by-id keine Rolle!
Sollte das HM-MOD-RPI-PCB über USB angebunden sein kann das über by-id erfolgen.
Zitat von: topcrown am 10 Dezember 2020, 20:32:31
@kiter1988
ExecStart=/usr/bin/deCONZ --platform minimal --auto-connect=1 --http-port=8880 --ws-port=8887 --dev=/dev/serial/by-id/usb-dresden_elektronik_ingenieurtechnik_GmbH_ConBee_II_DE2225162-if00
Grüße,
Thilo
So hab ichs vorhin eingetragen, danach zickte der HM noch mehr.
Nach einem shutdown mit "Strom weg" beim RPi geht's dann wieder für eine bestimmte zeit.
Zitat von: Otto123 am 10 Dezember 2020, 20:50:08
Sollte das HM-MOD-RPI-PCB über USB angebunden sein kann das über by-id erfolgen.
Das Modul ist ganz gewöhnlich auf die GPIO des RPi gesteckt.
Ich habe allerdings noch mehr Dinge auf dem RPi laufen.
Pi-hole, fhem, deconz und Homebridge.
Evtl. hats damit was zu tun.
Alle Programme haben anderen Ports.
Zitat von: topcrown am 09 Dezember 2020, 16:23:14
Also, mein Aufruf in deconz.service lautet nun
ExecStart=/usr/bin/deCONZ --platform minimal --auto-connect=1 --http-port=8880 --ws-port=8887 --dev=/dev/serial/by-id/usb-dresden_elektronik_ingenieurtechnik_GmbH_ConBee_II_DE2225162-if00
Ich habe das gleiche Problem und nun die deconz.service entsprechend geändert, allerdings ohne erfolg. Bei mir ist die USB-Dresden Schnittstelle allerdings auch auf ttyACM0 umgelinkt... war das bei euch nicht so :
ls -lah /dev/serial/by-id/
lrwxrwxrwx 1 root root 13 Feb 28 10:55 usb-dresden_elektronik_ingenieurtechnik_GmbH_ConBee_II_DE2400955-if00 -> ../../ttyACM0
Wo soll die denn sonst hinzeigen?
Das ist doch ok. Du kannst entweder by-id oder mit ACM0 einbinden.
--dev=/dev/ttyACM0
by-id ist sicherer, die id muss natürlich Deine sein :)
hmm aber weiter oben schreibst du
Zitat
Der deconz.service muss so konfiguriert sein dass es er nur die entsprechende Schnittstelle verwendet und /dev/ttyAMA0 in Ruhe lässt.
HMUARTLGW bindet das Modul normal über /dev/ttyAMA0 ein - da dies keine USB Schnittstelle ist, spielt hier by-id keine Rolle!
Also sollte Deconz doch nicht mit ttyAMA0 arbeiten, oder hab ich da was falsch verstanden ...
Ich habe jetzt mal alle Services angeschaltet, also auch den WIFI und Update Servcie der von deconz noch laufen ...
aber ich bekomme trotzdem ständig weiter das die Meldung :
2021-02-28 21:21:17 HMUARTLGW myHmUART cond: disconnected
2021-02-28 21:21:17 HMUARTLGW myHmUART CONNECTED
und sämtliche Homeatic devices sind nicht mehr ansprechbar ....woran kann es jetzt noch liegen ?
deconz versucht sich alle seriellen Schnittstellen zu greifen - wenn Du nicht sagst welche er nehmen soll.
USB Schnittstellen sind nur ein Teil der seriellen Schnittstellen
aber das mache ich doch durch den Aufruf --dev ....
ExecStart=/usr/bin/deCONZ --platform minimal --auto-connect=1 --http-port=8880 --ws-port=8887 --dev=/dev/serial/by-id/usb-dresden_elektronik_ingenieurtechnik_GmbH_ConBee_II_DE2400955-if00
dann ist eigentlich alles richtig. Das Du ein Problem mit HMUART hast schreibst Du erst später.
Ohne deconz läuft/lief das HMUART Modul?
Zitat von: Otto123 am 28 Februar 2021, 22:11:27
dann ist eigentlich alles richtig. Das Du ein Problem mit HMUART hast schreibst Du erst später.
Ohne deconz läuft/lief das HMUART Modul?
genau ich kann es mir auch nicht erklären ... mein HM lief seit knapp 3 Jahren total stabil.. ich hab den Stick reingesteckt , die Deconz Software installiert und jetzt läuft es nicht mehr , selbst dann nicht, wenn ich den Stick abziehe ... ratlos ...
attr initialUsbCheck disable 1 hast Du gesetzt? Also initialUsbCheck ausgeschaltet?
Ich fische im Trüben, ich habe bei einem Freund deconz an einem Pi mit HMUART Modul genau so installiert wie hier beschrieben. Das funktionierte...
Das Verhalten hatte ich früher, bevor ich die richtigen Optionen gekannt hatte.
Um das Modul wieder gangbar zu machen, reicht es nicht, den deconz Stick abzuziehen.
Bitte den kompletten Raspi runterfahren, vom Strom trennen! Warten, die genaue Zeit weiß ich nicht, probieren mal 10 Minuten. Dann wieder anschließen und hochfahren.
Zitat von: jhohmann am 01 März 2021, 15:30:24
Das Verhalten hatte ich früher, bevor ich die richtigen Optionen gekannt hatte.
Um das Modul wieder gangbar zu machen, reicht es nicht, den deconz Stick abzuziehen.
Bitte den kompletten Raspi runterfahren, vom Strom trennen! Warten, die genaue Zeit weiß ich nicht, probieren mal 10 Minuten. Dann wieder anschließen und hochfahren.
Also als ich das gelesen habe, dachte ich zunächst an Erdstahlen und Wasseradern, aber du hast RECHT! Nachdem ich den Raps 10 Min getrennt hatte , lief alles wieder wie vorher.
So jetzt scheint sich also das Deconz Modul an die richtige Schnittstelle zu binden und die andere in Ruhe zu lassen.
@Otto : InitialUSBCheck war nicht gesetzt und ich habe es jetzt drin. Es ist auch unter everything (nach einem Neustart) jetzt zu finden.... sollte also passen ...
ABER : Es werden immer noch keine Sensoren gefunden ... ARGH... Eine Fehlermeldung hab ich jetzt eigentlich nicht mehr ...
Halt stop, ich habe den Sensor falsch bedient... es geht doch jetzt ...
also der entscheidende und wichtige Hinweis hier war: Strom raus, Kaffee trinken , Strom an ... ;) vielen Dank soweit ...
Zitat von: lynckmeister am 01 März 2021, 21:25:13
Also als ich das gelesen habe, dachte ich zunächst an Erdstahlen und Wasseradern, aber du hast RECHT! Nachdem ich den Raps 10 Min getrennt hatte , lief alles wieder wie vorher.
Ich hatte ganz am Anfang den Fall: Strom aus hat nicht gereicht, man musste das Modul vom GPIO abziehen und eine Weile ab liegen lassen. Eventuell verkürzt das nur die Wartezeit.