Hallo Zusammen,
komme gerade aus dem Urlaub zurück und alle meine HomeMatic Devices funktionieren seit einem täglichen Neustart(Samstagmorgen) mit IOErr im State nicht mehr. Betroffen sind Rolloschalter und alle Schaltaktoren und die Zisternesteuerung.
Die FS20 Devices funktionieren, aber auch nicht alle. ent "0.00 W" isn't numeric in
Global Verbose habe ich auf 5 gestellt. Hat jemand eine Idee für mich.
Der Internetzugang war gestört, funktioniert jetzt aber wieder. Neustart von Raspi und Fhem haben nichts gebracht.
Gruß Günter
Zitat von: Gueco315 am 18 September 2016, 13:08:10
Global Verbose habe ich auf 5 gestellt. Hat jemand eine Idee für mich.
Schön! Und? Was interessantes im Log?
Was für einen IO verwendest du denn für deine HM-Komponenten?
Hast du denn ein Backup, das du ggf. mal wiedereinspielen könntest, wenn auch nur Testweise?
Mal die SD-Karte gewechselt?
Sooo viele Möglichkeiten ....
Hallo Benni,
ich habe 2 CUL-Sticks im Einsatz, 1x FS20 und 1x für HomeMatic. Wie spiele ich das Backup ein?
Worauf sollte ich im Log suchen? Die Devices stehen beim Anklicken im State: RESPONSE TIMEOUT:RegisterRead; Missing Ack oder IOErr ...
Gruß Günter
Wenn ich ein HomeMatic Device einschalten will steht im Event LOG:
2016-09-18 13:39:27.653 CUL_HM Flur_EGi set_on
2016-09-18 13:39:29.825 CUL CUL_1 DISCONNECTED
Hilft euch das?
welchen status zeigt den de rcul stick den du für homematic nutzt? es sieht so als aus wäre dein ioDev (der cul ) nicht verbunden/erkannt/what ever. somit kannst du natürlich auch nichts schalten
Stimmt, er ist im Status Disconnected! Warum auf einmal, das System lief seit Monaten fehlerfrei.
Wie bekomme ich das korrigiert?
Im einfachsten Fall noch mal ein Neustart machen
das habe ich schon mehrfach gemacht, ohne Erfolg.
Nun habe ich:
define initialUsbCheck notify global:INITIALIZED usb create aktiviert, beim Neustart taucht ein weiterer CUL_2 in der CFG-Datei auf, mit dem Status Initialized auf. Jedoch beziehen sich die Devices auf die FS20-Devices.
Übernehme ich diese Werte für den CUL_1 = HomeMatic-USB-Stick und aktiviere dazu den HomeMatic Modus, dann steigt der CUL auch mit einem Disconnect einfach wieder aus. Warum?
Stick ist nun initialisiert ...
### ttyACM0: checking if it is a CUL
ttyACM0 is already used by the fhem device CUL_0
### ttyACM1: checking if it is a CUL
ttyACM1 is already used by the fhem device CUL_1
### ttyAMA0: checking if it is a CUL
got wrong answer for a CUL
### ttyAMA0: checking if it is a TCM_ESP3
got wrong answer for a TCM_ESP3
### ttyAMA0: checking if it is a FRM
got wrong answer for a FRM
### ttyUSB0: checking if it is a TCM_ESP3
ttyUSB0 is already used by the fhem device myJeeLink
Zugriff auf HomeMatic Devices aber immer noch nicht möglich.
.. nach Schaltung eines HomeMatic Devices springt der Status wieder auf disconnected ,,
poste mal ein list deines homematic-culs. schau nach dem einstecken auch mal in der console mit dmesg nach ob da der cul sauber erkannt wird. je nach dem wie du ihn eingebunden hast wird evtl der falsche als hm-stick erkannt. ist es ein selbstbau oder ein originaler?
Hallo Chris,
es ist ein original USB-Stick von Busware ..
Internals:
CMDS BCFiAZEGMKURTVWXefmltux
CUL_1_MSGCNT 5
CUL_1_TIME 2016-09-18 16:17:37
Clients :CUL_HM:HMS:CUL_IR:STACKABLE_CC:
DEF /dev/ttyACM1@9600 1034
DeviceName /dev/ttyACM1@9600
FHTID 1034
NAME CUL_1
NR 32
NR_CMD_LAST_H 2
PARTIAL
RAWMSG A0CBD847036C29200000000E8342D
RSSI -51.5
STATE disconnected
TYPE CUL
VERSION V 1.58 CUL868
initString X21
Ar
Matchlist:
1:CUL_HM ^A....................
8:HMS ^810e04....(1|5|9).a001
D:CUL_IR ^I............
H:STACKABLE_CC ^\*
Readings:
2016-09-18 16:17:13 cmds B C F i A Z E G M K U R T V W X e f m l t u x
2016-09-18 16:17:39 state disconnected
XMIT_TIME:
1474208256.80363
1474208256.8354
Helper:
354e77:
QUEUE:
Attributes:
hmId FF2345
model CUL
rfmode HomeMatic
verbose 5
was sagt denn ein ls -l /dev/serial/by-id ? du kannst ruhig fie code und quote tags zur besseren leserlichkeit nutzen ;-)
Hm, weiß nicht wie das geht, hier das ls ..
pi@raspberrypi ~ $ ls -l /dev/serial/by-id
total 0
lrwxrwxrwx 1 root root 13 Sep 18 16:17 usb-busware.de_CUL868-if00 -> ../../ttyAC M2
lrwxrwxrwx 1 root root 13 Jan 1 1970 usb-FTDI_FT232R_USB_UART_AJ02W9F9-if00-po rt0 -> ../../ttyUSB0
pi@raspberrypi ~ $
Ich habe auf den USB-Ports am Raspi 1x CUL 868 für FS20, 1x CUL 868 für HomeMatic(Pflegefall), einen JeeLInk und 1 Bluetooth USB-Stick für die Presence Geschichten..
pi@raspberrypi ~ $ ls -l /dev/serial/by-id
total 0
lrwxrwxrwx 1 root root 13 Sep 18 16:17 usb-busware.de_CUL868-if00 -> ../../ttyACM2
lrwxrwxrwx 1 root root 13 Jan 1 1970 usb-FTDI_FT232R_USB_UART_AJ02W9F9-if00-port0 -> ../../ttyUSB0
du hast also 2 uls dran.
deine def des hm-cul von busware ist falsch/ hat sich nach dem reboot verändert.
probier mal
ZitatDEF /dev/ttyACM2@9600 1034
statt ACM1 wenn das nicht der für fs20 ist
Hallo Chris,
alles so wie von dir vorgeschlagen eingestellt:
define CUL_0 CUL /dev/ttyACM0@9600 0000
attr CUL_0 model CUL
attr CUL_0 rfmode SlowRF
#CUL für Homematic-Geräte
#define CUL_1 CUL /dev/ttyACM1@9600 1034
define CUL_1 CUL /dev/ttyACM2@9600 1034
attr CUL_1 hmId FF2345
attr CUL_1 model CUL
attr CUL_1 rfmode HomeMatic
Nach Reboot bleibt CUL_1 bleibt leider immer noch disconnected ...
pi@raspberrypi ~ $ ls -l /dev/serial/by-id
total 0
lrwxrwxrwx 1 root root 13 Jan 1 1970 usb-busware.de_CUL868-if00 -> ../../ttyACM1
lrwxrwxrwx 1 root root 13 Jan 1 1970 usb-FTDI_FT232R_USB_UART_AJ02W9F9-if00-port0 -> ../../ttyUSB0
USB Scan ergibt:
### ttyACM0: checking if it is a CUL
ttyACM0 is already used by the fhem device CUL_0
### ttyACM1: checking if it is a CUL
got wrong answer for a CUL
### ttyACM1: checking if it is a TCM_ESP3
got wrong answer for a TCM_ESP3
### ttyACM1: checking if it is a ZWDongle
got wrong answer for a ZWDongle
### ttyACM1: checking if it is a FRM
got wrong answer for a FRM
### ttyAMA0: checking if it is a CUL
got wrong answer for a CUL
### ttyAMA0: checking if it is a TCM_ESP3
got wrong answer for a TCM_ESP3
### ttyAMA0: checking if it is a FRM
got wrong answer for a FRM
### ttyUSB0: checking if it is a TCM_ESP3
ttyUSB0 is already used by the fhem device myJeeLink
Mit den Code Tags ist das hier gemeint:
noch ein Hinweis,
komischerweise funktionieren andere Funktionen wie notifys etc. bei den FS20 Devices auch nicht mehr ...
Hat sich meine Fhem Umgebung "in meinem Urlaub" auf einmal verselbstständigt?
Schon mal den usb-check deaktiviert!?
Einbinden per /dev/serial/by-path probiert!?
Solange man nichts umsteckt überlebt das auch einen reboot...
Mal einen nach dem anderen stecken und dann mal ls /dev/serial/by-path/
Hab auf meinen PIs alle meine usb-CULs etc. so eingebunden...
Gruß, Joachim
pi@raspberrypi ~ $ ls -l /dev/serial/by-path
total 0
lrwxrwxrwx 1 root root 13 Sep 18 19:19 platform-3f980000.usb-usb-0:1.2.4:1.0 -> ../../ttyACM0
lrwxrwxrwx 1 root root 13 Jan 1 1970 platform-3f980000.usb-usb-0:1.4:1.0-port0 -> ../../ttyUSB0
lrwxrwxrwx 1 root root 13 Jan 1 1970 platform-3f980000.usb-usb-0:1.5:1.0 -> ../../ttyACM1
pi@raspberrypi ~ $
usb-check schon disabled?
attr initialUsbCheck disable 1
Wenn du einen nach dem anderen steckst und dann jeweils ls /dev/serial/by-path/ eingibst, dann siehst du welcher welcher ist.
Für den define in fhem nutzt du dann beispielsweise '/dev/serial/by-path/platform-3f980000.usb-usb-0:1.2.4:1.0'
bzw. halt für den jeweiligen USB-CUL etc. was immer neu bei ls dazu kam...
Bei mir sieht es für den CUL so aus:
define nanoCUL_HM TSCUL /dev/serial/by-path/platform-3f980000.usb-usb-0:1.5:1.0-port0@38400 1111
Gruß, Joachim
Klingt gut, woher bekommen ich die "z. B:" port0@38400 1111 Angaben ?
Zitat von: Gueco315 am 18 September 2016, 19:32:46
pi@raspberrypi ~ $ ls -l /dev/serial/by-path
total 0
lrwxrwxrwx 1 root root 13 Sep 18 19:19 platform-3f980000.usb-usb-0:1.2.4:1.0 -> ../../ttyACM0
lrwxrwxrwx 1 root root 13 Jan 1 1970 platform-3f980000.usb-usb-0:1.4:1.0-port0 -> ../../ttyUSB0
lrwxrwxrwx 1 root root 13 Jan 1 1970 platform-3f980000.usb-usb-0:1.5:1.0 -> ../../ttyACM1
pi@raspberrypi ~ $
soweit alles überprüft, die CUL's stimmen nun ..
pi@raspberrypi ~ $ ls -l /dev/serial/by-path
total 0
lrwxrwxrwx 1 root root 13 Sep 18 20:05 platform-3f980000.usb-usb-0:1.2.4:1.0 -> ../../ttyACM0
lrwxrwxrwx 1 root root 13 Jan 1 1970 platform-3f980000.usb-usb-0:1.4:1.0-port0 -> ../../ttyUSB0
lrwxrwxrwx 1 root root 13 Jan 1 1970 platform-3f980000.usb-usb-0:1.5:1.0 -> ../../ttyACM1
pi@raspberrypi ~ $
Beide CUL's sind initialisiert. Beim Betätigen eines HomeMatic Devices kommt nun folgende Meldung:
2016-09-18 20:06:56.417 CUL_HM Flur_EGi set_on
2016-09-18 20:06:57.961 CUL CUL_1 UNKNOWNCODE ERR:CCA
??
Zitat von: Gueco315 am 18 September 2016, 20:08:06
Beide CUL's sind initialisiert. Beim Betätigen eines HomeMatic Devices kommt nun folgende Meldung:
2016-09-18 20:06:56.417 CUL_HM Flur_EGi set_on
2016-09-18 20:06:57.961 CUL CUL_1 UNKNOWNCODE ERR:CCA
??
Hmmm, da müsste/sollte mal jemand drüber schauen, der mehr bzgl. CUL etc. weiß.
Bzw. mal ein list deiner CULs etc. hier posten (aber ruhig mal die '#' code Tags verwenden!) und auch mal sehen was ein 'get ccconf' bzw. 'get version' etc. liefern...
Gruß, Joachim
zieh mal alles usb-seitige ab und teste mal nur den cul für hm einzeln. du hast ja scheinbar 2 cul + 1 jeelink direkt am pi oder?
Hallo,
Zitat von: Gueco315 am 18 September 2016, 20:08:06
2016-09-18 20:06:57.961 CUL CUL_1 UNKNOWNCODE ERR:CCA
Clear channel assessment konnte nicht erfolgreich durchgeführt werden -> Du hast einen Dauersender auf 868.35MHz irgendwo, der stört.
Viele Grüße
Michael
so, nur noch den HomeMatic Cul angeschlossen, die Fehlermeldung bleibt:
2016-09-19 10:44:30.359 CUL_HM Flur_EGi set_on
2016-09-19 10:44:31.437 at Time_Update Next: 10:44:41
2016-09-19 10:44:31.904 CUL CUL_1 UNKNOWNCODE ERR:CCA
2016-09-19 10:44:34.074 CUL CUL_1 UNKNOWNCODE ERR:CCA
2016-09-19 10:44:38.111 CUL CUL_1 UNKNOWNCODE ERR:CCA
2016-09-19 10:44:41.423 at Time_Update Next: 10:44:51
2016-09-19 10:44:42.332 CUL CUL_1 UNKNOWNCODE ERR:CCA
2016-09-19 10:44:44.885 CUL_HM Flur_EGi ResndFail
2016-09-19 10:44:44.915 CUL_HM Flur_EGi MISSING ACK
Was könnte stören??
Wie kann ich den Port, z. B. @9600 1034 beim Raspi abfragen?
define CUL_1 CUL /dev/ttyACM0@9600 1034
define CUL_0 CUL /dev/ttyACM1@9600 0000
Vielleicht ist da etwas falsch eingetragen oder hat sich geändert.
Zitat von: mgernoth am 19 September 2016, 10:28:35
Hallo,
Clear channel assessment konnte nicht erfolgreich durchgeführt werden -> Du hast einen Dauersender auf 868.35MHz irgendwo, der stört.
Viele Grüße
Michael
Dem würde ich mal nachgehen, wenn irgendein Störsignal auf 868.35MHz deine HM devices überlagert, kann da nicht's funktionieren!
VG
Frank
Z.B. mit minicom oder einem anderen serial-terminal-programm.
Dann aber vorher fhem beenden da sonst die Schnittstelle ja bereits belegt ist...
sudo apt-get install minicom
sudo minicom -b 9600 -D /dev/ttyAMA0
bzw.
sudo minicom -b 9600 -D /dev/ttyAMA0 -o
okay ..
pi@raspberrypi ~ $ sudo minicom -b 9600 -D /dev/ttyAMA0
Welcome to minicom 2.6.1
OPTIONS: I18n
Compiled on Apr 28 2012, 19:24:31.
Port /dev/ttyAMA0
Press CTRL-A Z for help on special keys
Neue SD-Karte genommen, immer noch das gleiche Bild. Werde FHEM komplett neu aufsetzten und berichten ...
Hallo Comunity,
FHEM komplett auf neue MicroSD neu aufgesetzt.
Die ERR-Meldung kommt nicht mehr, bei Schalten connected sich der Actor mit dem CUL Status Connected, dann Disconnected er sich wieder.
Kann es sein, dass ich die Aktoren alle wieder neu anlernen muss?
Wenn die HMID die selbe wie zuvor (bzw. beim Anlernen) war dann nicht...
Aber mal den Hinweis auf die Funklast/Störsender beachten...
habe ich verwendet. Störsender/Funklast, hier habe ich/wurde nichts neu installiert. Das Phänomen ist nach einem Neustart. Auch einige FS20 Aktoren reagieren auch nicht mehr auf die Befehle. Es ist mir total unerklärlich und Mysteriös. Im Prinzip kann es doch jetzt nur noch mit den CUL's zusammenhängen, oder? Eventuell neu flashen und ein neue Fw aufspielen?? Was meint ihr?
Zitat von: franky08 am 19 September 2016, 11:45:42
Dem würde ich mal nachgehen, wenn irgendein Störsignal auf 868.35MHz deine HM devices überlagert, kann da nicht's funktionieren!
VG
Frank
was könnte das sein? LTE??
Hallo,
im Normalfall ist das irgendein abgestürztes Homematic/FS20 Gerät. Alle(!) mal stromlos machen, dann sollte es hoffentlich wieder gehen.
Evtl. haben Deine CULs unterschiedliche Firmwareversionen, dann verhalten sie sich unterschiedlich. Die CCA-Meldung ist "relativ" neu, davor ist der CUL in dem Fall abgestürzt (disconnected/connected).
Viele Grüße
Michael
@Alle,
herzlichen Dank für eure Unterstützung. Mein FHEM läuft nun wieder einwandfrei.
Ich habe in der CFG-Datei 2 Abschnitte mit "#hurz" auskommentiert, die UWZ-Funktion mit 2 DOIF'S (muss nicht die Ursache gewesen sein!!!!!) und ..
eine FBDECT-STeckdosen-Schaltung womit ich meine Ebikes auflade. Eigentlich hatte das immer super funktioniert. Hier der Code:
#Hurz attr FileLog_Ebikeload fm_type [{"title":"Power","id":"graph-power","min":"0","max":"auto:10","col":"7f7f00","h":3}]
und
#hurz define Ebike_di DOIF ([Ebikeload:power]>10) (set BikeloadBetrieb on) DOELSEIF ([Ebikeload:power]<7) (set BikeloadBetrieb off, {fhem ("set Pushover msg 'zu Hause' 'Ebikes\nDie Akkus sind jetzt aufgeladen!' '' 0 ''")})
#hurz attr Ebike_di room hidden
#hurz attr Ebike_di wait 60:120
Unter Umständen haben diese Aufrufe so viel Traffic erzeugt, dass kaum noch ein Telegramm durchgegangen ist.
Also mein FHEM läuft jetzt wieder so wie es sollte, nochmals herzlichen Dank an ALLE!!
Jetzt kann ich mit dem Ausbau fortfahren.
Gruß Günter