Hallo zusammen,
ich will mit dem Thema Hausautomation anfangen und habe mich für Z-Wave entschieden.
Dabei nutze ich als Zentrale einen RaspberryPi 3 B+ und das Razberry 2Modul.
Zunächst hatte ich mit OpenHab, dann Z-Way und dann mit OpenRemote rumhantiert, aber alle waren mehr oder weniger gut...
Z-Way gefiel mir bis dato am besten, da hier die EInrichtung und Anpassung sehr professionel und einfach war. Aber es fehlte an vielen nützlichen Dingen und die Entwicklung dr Komponenten ist etwas mau...
Jetzt bin ich auf FHEM umgestiegen. Da muss ich noch die passende GUI finden :)
Aber es geht shcon los mit dem Einrichten des Razberry Moduls...
Das steht in der Oberfläche jetzt drin:
ZWDongle
ZWAVE1
Initialized
Eingerichtet über folgenden Befehl:
define ZWAVE1 ZWDongle /dev/ttyAMA0@115200
Die Einrichtung der Serial-Schnittstelle etc. ist shocn erledigt, da die Platine vorher mit Z-Way funktioniert hat.
Z-Way ist noch installiert, der Dienst jedoch beendet.
OpenRemote hab ich deinstalliert
Wenn ich jetzt jedoch versuche den Befehle "get ZWave1 homeId" aufzurufen (wie in Tutorials zu lesen) bekomme ich folgende Meldung:
homeId is unsupported by this controller
Daten des Gerätes in der Oberfläche werden wie folgt angezeigt:
Internals
CFGFN
CallbackNr 0
Clients :ZWave:
DEF /dev/ttyAMA0@115200
DeviceName /dev/ttyAMA0@115200
FD 7
MaxSendRetries 3
NAME ZWAVE1
NR 30
PARTIAL
ReadTime 1544917140.30728
STATE Initialized
SendRetries 0
SendTime 1544917140.30518
TYPE ZWDongle
WaitForAck 0
nrNAck 4
Readings
state Initialized 2018-12-16 00:38:58
Im Log steht folgendes:
2018.12.16 00:38:55 3: Opening ZWAVE1 device /dev/ttyAMA0
2018.12.16 00:38:55 3: Setting ZWAVE1 serial parameters to 115200,8,N,1
2018.12.16 00:38:56 1: ZWAVE1: SOF missing (got 04 instead of 01)
2018.12.16 00:38:58 3: ZWAVE1 device opened
2018.12.16 00:38:58 2: ZWDongle_ProcessSendStack: no ACK, resending message 01030007fb
2018.12.16 00:38:58 1: ZWAVE1: SOF missing (got 04 instead of 01)
2018.12.16 00:38:59 2: ZWDongle_ProcessSendStack: no ACK, resending message 01030007fb
2018.12.16 00:38:59 1: ZWAVE1: SOF missing (got 04 instead of 01)
2018.12.16 00:39:00 2: ZWDongle_ProcessSendStack: no ACK, resending message 01030007fb
2018.12.16 00:39:00 1: ZWAVE1: SOF missing (got 04 instead of 01)
2018.12.16 00:39:01 2: ZWDongle_ProcessSendStack: no ACK, resending message 01030007fb
2018.12.16 00:39:01 1: ERROR: max send retries reached, removing 01030007fb from dongle sendstack
Wie kann ich sicher sein, dass die Platine richtig arbeitet?
Danke euch :)
Es klingt so, dass FHEM ueber /dev/ttyAMA0 das Razberry Modul nicht ansprechen kann.
Evtl. hat ein anderes Programm diese Schnittstelle offen (lsof | grep ttyAMA0) oder sie wird von der Konsole belegt.
Falls FHEM Zugang zum Geraet hat, dann legt FHEM mit der ausgelieferten Version der fhem.cfg wg.
Zitatdefine initialUsbCheck notify global:INITIALIZED usb create
automatisch ein ZWDongle an.
Bei mir zeit der LSOF Befehl folgendes an:
perl 590 fhem 7u CHR 204,64 0t0 1156 /dev/ttyAMA0
Sieht so aus als ob er sich das geschnappt hat.
Aber es kommt immer noch der Fehler.
Hier die Zeilen nach dem Reboot vom Pi im Log:
2018.12.17 14:36:16 0: Server shutdown
2018.12.17 14:36:31 1: Including fhem.cfg
2018.12.17 14:36:32 3: WEB: port 8083 opened
2018.12.17 14:36:32 2: eventTypes: loaded 211 events from ./log/eventTypes.txt
2018.12.17 14:36:32 3: Opening ZWAVE1 device /dev/ttyAMA0
2018.12.17 14:36:32 3: Setting ZWAVE1 serial parameters to 115200,8,N,1
2018.12.17 14:36:35 3: ZWAVE1 device opened
2018.12.17 14:36:36 1: Including ./log/fhem.save
2018.12.17 14:36:36 1: usb create starting
2018.12.17 14:36:37 1: usb create end
2018.12.17 14:36:37 0: Featurelevel: 5.9
2018.12.17 14:36:37 0: Server started with 19 defined entities (fhem.pl:17779/2018-11-18 perl:5.024001 os:linux user:fhem pid:590)
2018.12.17 14:36:37 2: ZWDongle_ProcessSendStack: no ACK, resending message 01030007fb
2018.12.17 14:36:38 2: ZWDongle_ProcessSendStack: no ACK, resending message 01030007fb
2018.12.17 14:36:38 1: ZWAVE1: SOF missing (got 04 instead of 01)
2018.12.17 14:36:39 2: ZWDongle_ProcessSendStack: no ACK, resending message 01030007fb
2018.12.17 14:36:40 2: ZWDongle_ProcessSendStack: no ACK, resending message 01030007fb
2018.12.17 14:36:40 1: ERROR: max send retries reached, removing 01030007fb from dongle sendstack
2018.12.17 14:37:36 3: telnetForBlockingFn_1545053856: port 38201 opened
JETZT Geht es :)
Die Anleitung ist da etwas "veraltet".
Folgender Befehl hat geholfen:
define ZWAVE1 ZWDongle /dev/serial0@115200
Wichtig hier:
serial0 statt bisher ttyAMA0
:)
Jetzt kann ich weiter machen
Danke fuer den Hinweis, ich habe serial.* in autocreate aufgenommen.
Hallo Rudolf,
seit dem Update der 98_autocreate vom Dezember treten bei mir folgende Störungen und Einträge im LOG auf Raspberry 3 auf:
... 1: usb create starting
... 1: ZWDongle: Can't open /dev/serial: Is a directory
... 1: define CUL_1 CUL /dev/ttyACM1@9600 1134
... 1: CUL_1: Cannot define multiple CULs with identical first two digits (11)
... 1: define CUL_1 CUL /dev/ttyACM1@9600 1134: CUL_1: Cannot define multiple CULs with identical first two digits (11)
... 1: usb create end
Meine ursprüngliche CUL-Definition (Busware-CUL) hatte als DEF /dev/ttyACM0@9600 1034. Damit hatte ich dann zwei CULs.
Der erste und bisher funktionierende war disconnected, bei dem neuen und automatisch angelegten fehlten natürlich Attr-Einträge - vom falschen Namen ganz abgesehen.
Als erste Maßnahme hatte ich autocreate disabled, jetzt bin ich wieder zur alten Version zurück, habe 98_autocreate bei den Updates ausgeschlossen und die FHEM-Welt ist wieder in Ordnung.
Kannst Du das mal überprüfen und ggf. fixen? Die ZWDongle-Fehlermeldung wurde auch hier erwähnt: https://forum.fhem.de/index.php/topic,94918.msg877074.htm
Danke! Gruß
Achim
Kannst du bitte die "alte" Definition aller USB Geraete in FHEM zeigen, die define Zeile mit dem Pfad interessiert mich.
Uebrigens: statt autocreate zu deaktivieren ist es viel ratsamer die "usb create" Zeile in fhem.cfg zu deaktivieren (disable)
Als USB-Geräte am Raspberry 3 habe ich nur den Busware-CUL, keine anderen USB-Geräte.
Hier das Ergebnis von "list CUL_0":
Internals:
CMDS BbCFiAZNkGMKUYRTVWXefmLltux
CUL_0_MSGCNT 59
CUL_0_TIME 2018-12-30 10:27:31
Clients :CUL_HM:HMS:CUL_IR:STACKABLE_CC:TSSTACKED:STACKABLE:
DEF /dev/ttyACM0@9600 1134
DeviceName /dev/ttyACM0@9600
FD 21
FHTID 1134
NAME CUL_0
NR 300
NR_CMD_LAST_H 23
PARTIAL
RAWMSG A1423845E32B15D000000823137000024003008FA011C
RSSI -60
STATE Initialized
TYPE CUL
VERSION V 1.66 CUL868
initString X21
Ar
owner_CCU HM_VCCU
.attraggr:
.attrminint:
.clientArray:
CUL_HM
MatchList:
1:CUL_HM ^A....................
8:HMS ^810e04....(1|5|9).a001
D:CUL_IR ^I............
H:STACKABLE_CC ^\*
M:TSSTACKED ^\*
N:STACKABLE ^\*
READINGS:
2018-12-30 09:44:02 cmds B b C F i A Z N k G M K U Y R T V W X e f m L l t u x
2018-12-30 10:07:13 raw is000FFFF00FF0
2018-12-30 10:27:31 state Initialized
XMIT_TIME:
1546159443.02988
1546159443.07395
1546159456.68227
1546159456.73595
1546159515.19728
1546159653.85131
1546159688.99681
1546159768.06078
1546159935.19309
1546160088.87619
1546160228.01219
1546160353.92827
1546160527.35047
1546160687.06532
1546160832.48878
1546160964.45424
1546161082.09195
1546161247.84924
1546161399.56259
1546161537.26862
1546161660.97044
1546161832.73965
1546161990.97759
helper:
32B15D:
QUEUE:
52CC52:
QUEUE:
56CC14:
QUEUE:
5FB003:
QUEUE:
Attributes:
hmId FA1034
rfmode HomeMatic
room System
Die /dev/serial Warnung habe ich gefixt.
Wg. der anderen Meldung: die alte Definition wurde automatisch mit "ACM0, 1034" angelegt.
Das hast du irgendwannmal zu "ACM0, 1134" geaendert, deswegen kann jetzt kein "ACM1, 1134" angelegt werden.
Die manuelle Aenderung war vmtl. noetig, weil linux nach einem reboot USB-Geraete manchmal nicht dem gleichen /dev/ttyACM* zuordnet.
Loesung #1: usb create in fhem.cfg deaktivieren, und die CUL Definition "per Hand" reparieren.
Loesung #2: alle CUL Definitionen entfernen, CUL automatisch anlegen per "usb create", CUL Umbenennen so, dass die alten abhaengigen Definitionen sie wiederfinden.
DANKE!
Habe mich für Gürtel und Hosenträger entschieden:
CUL gelöscht, neu gestartet, CUL wurde richtig mit 1034 neu angelegt.
Neu gestartet, noch alles i.O., rfmode und hmid i.O.
Neu gestartet, alles funktioniert
usb create in fhem.cfg deaktiviert.
Gruß
Achim
Hallo,
möchte gerne nochmals das Thema aufgreifen, da ich genau das gleiche Problem imme rnoch habe.
Folgendes gemacht Pi3 B lief nicht mehr flüssig, habe dort dann rpi-update durchgeführt, die geclonte SD in den neuen Pi3 B+ rein und alles läuft wie gewohnt, nur habe ich da Razberry-Modul vom alte Pi abgezogen und in den neuen gesteckt.
an der cmdline.txt und der config.txt nichts geändert. Jetzt habe ich keine Zugriff mehr auf meine Zwave Defines.
Mein Log:
Opening ZWAVE1 device /dev/ttyAMA0
Setting ZWAVE1 serial parameters to 115200,8,N,1
ZWAVE1 device opened
ZWDongle_ProcessSendStack: no ACK, resending message 01030007fb
Jetze lese ich oben, das ttyACM0 verkehrt sein soll?! Muss dann nich auch noch die cmdline.txt angepasst werden. USB Create habe ich deaktiviert und das Modul von Hand angelegt.
define ZWAVE1 ZWDongle /dev/ttyAMA0@115200
Sollte es dann so definiert werden?
define ZWAVE1 ZWDongle /dev/serial0@115200
und die cmdline.txt auch geändert werden?
Genau das kommt bei mir auch und die caps können auch nicht abgerufen werden, hoffe das Modul ist nicht defekt!
Wenn ich jetzt jedoch versuche den Befehle "get ZWave1 homeId" aufzurufen (wie in Tutorials zu lesen) bekomme ich folgende Meldung:
homeId is unsupported by this controller
ZitatJetze lese ich oben, das ttyACM0 verkehrt sein soll?!
Wenn ich keine Ahnung haette, wie das Razberry eingebunden wird, dann wuerde ich (wie in meinem Antwort #8 erwaehnt):
ZitatLoesung #2: alle CUL Definitionen entfernen, CUL automatisch anlegen per "usb create", CUL Umbenennen so, dass die alten abhaengigen Definitionen sie wiederfinden.
Oder eine Ahnung besorgen: dmesg studieren, /dev/ komplett ansehen, im Internet lesen, probieren.
Oder den Hersteller des Geraetes oder des Betriebsystems fragen, schliesslich ist nicht FHEM daran Schuld, dass Razberry nicht da eingebunden ist, wo es auf dem alten Hardware mit dem alten OS war.
Erledigt! Controller war defekt. Neuen besorgt, alles geht, außer das ich kein Backup von den Zwave-Defines hatte.
Alles neu inkludiert, klappt wieder. Trotzdem danke für deine fachmännische Antwort.