Mit der Version 6098 (gestern nachmittag) von 10_CUL_HM bekomme ich bei meinen Schaltaktoren generell nur noch MISSING ACK.
Mit der Version 6096 (gestern vormittag) tritt der Fehler nicht auf.
Ich glaube ich werde versuchen auf die Version zurück zu gehen, wo auch das Problem mit dem unknown nicht auftrat. Allerdings bin ich in Linux nicht fit und weiß nicht wie ich das aus dem
Backup zurück hole.
Gruß
Jens
Gesendet von meinem iPhone mit Tapatalk
Hallo Jens,
ich mache das immer mit Windows. Allzip kann auch tar entpacken. Ansonsten mal "man tar" auf dem Raspi-Terminal eingeben. Da sollten die man(ual) Seiten für den tar Befehl kommen. Dem muss man dann noch sagen, dass die Datei gepackt ist - dann kann man damit die Dateien wieder auspacken und die benötigte zurück kopieren.
Gruß Christoph
Kann ich bestätigen - seit einem Update eben selbiges Problem; Auch bei Dimmern ist es der Fall (die bleiben auf set_ stehen) ... des weiteren scheint FHEM gerade sehr instabil zu sein und stürzt ab ... wobei genau muss ich mal noch isolieren.
...ich aknn ebenfalls bestätigen, daß seit dem Update heute morgen die Homematic-Devices micht mehr ansprechbar sind (MISSING ACK). Mit der 10_CUL_HM von gestern geht es aber wieder.
Gruß
Blueberry63
...ich such mir schon den ganzen Tag den Wolf nach dem Fehler... ;)
Bei mir das gleiche Thema...
Gibt es denn schon eine Idee, woran es liegen könnte, so dass ich auf das nächste Update warten kann?
Der Fehler tritt übrigens nicht bei alles Sendevorgängen auf, ganz wenige Befehle gehen so durch...
Viele Grüße
Eniac
Die Sendevorgänge für Schaltbefehle gehen eigentlich alle durch, aber die Rückmeldung wird in fhem nicht korrekt ausgewertet.
Ich denke, sobald martin den Thread hier entdeckt hat, wird er sich sicher um die Fehlerbehebung kümmern. Mit der Modulversion von gestern früh bin ich jedenfalls (bis auch zwei warnings beim fhem Start) recht zufrieden.
gleicher Fehler bei mir.
File-compare bringt Änderungen aus dem screenshot.
Zurückspielen der alten 10_CUL_HM.pm behebt den Fehler.
Hallo - neben dem MISSING ACK meiner Schalt- und Dimmaktoren hatte ich auch keine Aktualisierung der Daten von meiner Wetterstation (HM-WDS100-C6-O) mehr erhalten. Nach Rücksetzen der 10_CUL_HM geht es wieder.
Da ich auch unzählige "Unknown code XXX Help me!" Meldungen aus Thread http://forum.fhem.de/index.php/topic,24370.0.html (http://forum.fhem.de/index.php/topic,24370.0.html) hatte (und die vccu bei mir nicht half) bin ich nun auf Version 6054 vom 04.06.14 der 10_CUL_HM zurück und habe nun wieder ein "sauberes" System (Raspi).
Bei mir kamen von meinen KFM100 Sensor keine Werte mehr an. Ich bin wieder auf die 6071 zurück.
Und ich bin - nicht lachen - auf die 5426 von Anfang April zurück. Damit hat alles wochenlang top funktioniert. In der letzten Zeit hatte ich nach Updates nur Probleme: Fehlermeldungen, falsche States im Webinterface, RHS quittiert nicht mehr grün sondern rot, Missing Ack usw.
Ich mache erstmal kein Update mehr bis sich die Post hier wieder auf Anfängerfragen reduzieren. :(
Ich bin auf die Version 6054 zurückgegangen (altes Backup eingespielt), nachdem ich den halben Abend daran verzweifelt bin, warum FHEM auf all meine HM-Devices nicht mehr reagiert (hab nur Sensoren die senden (Tür-Kontakt und KeyMatic)).
Im Log stand bei mir auch "unknown command ... help me!"
Hätte ich diesen Thread mal eher gefunden...
Nutze übrigens Busware COC und RPI.
Habe ebenfalls das o.g. Problem gestern Nachmittag nach einem update.
Heute Vormittag mit Freude die Aktualisierungen nach einem update check wahrgenommen, Fehler aber weiterhin vorhanden ???
Ich habe HMLAN am RPI, finde ich irgendwo die alte 00_HMLAN.pm?
edit: Schon gefunden ..., lesen bildet ;)
VersionsInfo:
# $Id: fhem.pl 6080 2014-06-07 16:12:09Z rudolfkoenig $
# $Id: 10_CUL_HM.pm 6098 2014-06-10 11:08:29Z martinp876 $
# $Id: 95_Dashboard.pm 5921 2014-05-21 18:47:19Z svenson08 $
# $Id: 01_FHEMWEB.pm 6090 2014-06-09 10:25:11Z rudolfkoenig $
# $Id: 92_FileLog.pm 5876 2014-05-16 19:54:51Z rudolfkoenig $
# $Id: 00_HMLAN.pm 6069 2014-06-05 14:21:43Z martinp876 $
# $Id: 99_SUNRISE_EL.pm 5851 2014-05-13 19:39:03Z rudolfkoenig $
# $Id: 98_SVG.pm 5956 2014-05-24 13:04:04Z rudolfkoenig $
# $Id: 99_Utils.pm 5488 2014-04-08 11:32:17Z rudolfkoenig $
# $Id: 90_at.pm 5319 2014-03-25 10:11:47Z rudolfkoenig $
# $Id: 98_autocreate.pm 5268 2014-03-20 20:46:00Z rudolfkoenig $
# $Id: 98_dummy.pm 4934 2014-02-15 08:23:12Z rudolfkoenig $
# $Id: 91_eventTypes.pm 5956 2014-05-24 13:04:04Z rudolfkoenig $
# $Id: 91_notify.pm 6081 2014-06-07 16:31:18Z rudolfkoenig $
# $Id: 98_structure.pm 5050 2014-02-26 08:29:44Z rudolfkoenig $
# $Id: 98_telnet.pm 4844 2014-02-08 07:54:03Z rudolfkoenig $
# $Id: 98_update.pm 6055 2014-06-04 09:45:24Z rudolfkoenig $
# $Id: 98_weblink.pm 5608 2014-04-23 10:57:16Z rudolfkoenig $
edit2:
Habe jetzt die alten Dateien eingespielt und alles ist gut. ;D
# $Id: 10_CUL_HM.pm 5989 2014-05-27 17:32:24Z martinp876 $
# $Id: 00_HMLAN.pm 5966 2014-05-25 07:48:27Z martinp876 $
Könnte man den Fred nicht mal ggf. vorübergehend pinnen? Ist doch wirklich wichtig...
Geht nich gips nich
Ich habe Martin gerade mal ´ne PM geschickt.
Hallo zusammen
nach der FHEMWiederherstellung des o.g.Probleme kann ich keine Aktoren mehr anlernen
es erscheint auch kein Eintrag in der Log (vom Pairing Versuch)
vielleicht reicht für die Spezialisten ein Blick in die Datei, ob der Fehler soft-oder hardwareseitig ist und überhaupt mit diesem Update zusammenhängt
habe leider keinen anderen HMLAN zum probieren vorrätig
bin für jede Hilfe dankbar
Gruss tagedieb
@tagedieb War bei mir in der strittigen Version auch so - Pairing ging nicht. Habe ein Paar neue Geräte die Tage (Außenthermometer, RT-DN) Revert der CUL_HM.pm (siehe erstes Post in diesem Thread) löste das Problem. In der Version stürzt FHEM zwar beim Pairen mit folgender Ausgabe in der Konsole ab ...
Use of uninitialized value $updt in concatenation (.) or string at ./FHEM/00_HMLAN.pm line 750.
Use of uninitialized value $updt in concatenation (.) or string at ./FHEM/00_HMLAN.pm line 752.
Can't use an undefined value as an ARRAY reference at ./FHEM/10_CUL_HM.pm line 766.
Can't use an undefined value as a symbol reference at FHEM/Blocking.pm line 130.
Can't use an undefined value as a symbol reference at FHEM/Blocking.pm line 130.
Can't use an undefined value as a symbol reference at FHEM/Blocking.pm line 130.
Can't use an undefined value as a symbol reference at FHEM/Blocking.pm line 130.
.. aber das Gerät ist, nachdem ich FHEM dann wieder neu gestartet habe, da:
Internals:
DEF 25FA26
HMLANGW_MSGCNT 3
HMLANGW_RAWMSG E25FA26,0000,04CE2F1A,FF,FFCD,01867025FA2600000000FE36
HMLANGW_RSSI -51
HMLANGW_TIME 2014-06-12 16:19:24
IODev HMLANGW
LASTInputDev HMLANGW
MSGCNT 3
NAME CUL_HM_HM_WDS10_TH_O_25FA26
NR 696
STATE ???
TYPE CUL_HM
lastMsg No:01 - t:70 s:25FA26 d:000000 00FE36
protLastRcv 2014-06-12 16:19:24
rssi_at_HMLANGW avg:-43.66 min:-51 max:-40 lst:-51 cnt:3
Readings:
2014-06-12 16:19:23 CommandAccepted yes
Helper:
Io:
newChn +25FA26,00,01,00
nextSend 1402582764.23331
rxt 0
p:
25FA26
00
01
00
Mrssi:
mNo 01
Io:
HMLANGW -49
Prt:
bErr 0
sProc 0
Rspwait:
Q:
qReqConf
qReqStat
Role:
chn 1
dev 1
Rssi:
At_hmlangw:
avg -43.6666666666667
cnt 3
lst -51
max -40
min -51
Attributes:
IODev HMLANGW
autoReadReg 4_reqStatus
expert 2_full
room CUL_HM
Allerdings ungepairt. Wenn man jetzt nochmal pairt, und dann n getConfig macht, ist alles gut, ohne Absturz:
Internals:
DEF 25FA26
HMLANGW_MSGCNT 20
HMLANGW_RAWMSG E25FA26,0000,04D588F8,FF,FFD8,04867025FA26000000010933
HMLANGW_RSSI -40
HMLANGW_TIME 2014-06-12 16:27:10
IODev HMLANGW
LASTInputDev HMLANGW
MSGCNT 20
NAME CUL_HM_HM_WDS10_TH_O_25FA26
NR 696
STATE T: 26.5 H: 51
TYPE CUL_HM
lastMsg No:04 - t:70 s:25FA26 d:000000 010933
protCmdDel 6
protLastRcv 2014-06-12 16:27:10
protResnd 6 last_at:2014-06-12 16:25:53
protResndFail 2 last_at:2014-06-12 16:25:58
protSnd 12 last_at:2014-06-12 16:27:05
protState CMDs_done
rssi_at_HMLANGW avg:-41.09 min:-51 max:-37 lst:-40 cnt:20
CHANGETIME:
Helper:
Dblog:
Activity:
Dblog:
TIME 1402583225.26631
VALUE alive
D-firmware:
Dblog:
TIME 1402583225.26631
VALUE 1.3
D-serialnr:
Dblog:
TIME 1402583225.26631
VALUE LEQ0029731
R-burstrx:
Dblog:
TIME 1402583192.52398
VALUE off
R-paircentral:
Dblog:
TIME 1402583192.52398
VALUE 0x34EF21
T:
Dblog:
TIME 1402583230.85833
VALUE 26.5 H
Battery:
Dblog:
TIME 1402583230.85833
VALUE ok
Humidity:
Dblog:
TIME 1402583230.85833
VALUE 51
State:
Dblog:
TIME 1402583158.87274
VALUE RESPONSE TIMEOUT:RegisterRead
Temperature:
Dblog:
TIME 1402583230.85833
VALUE 26.5
Readings:
2014-06-12 16:27:05 Activity alive
2014-06-12 16:26:32 CommandAccepted yes
2014-06-12 16:27:05 D-firmware 1.3
2014-06-12 16:27:05 D-serialNr LEQ0029731
2014-06-12 16:27:05 PairedTo 0x34EF21
2014-06-12 16:26:32 R-burstRx off
2014-06-12 16:26:32 R-pairCentral 0x34EF21
2014-06-12 16:27:05 RegL_00: 01:00 02:01 05:00 0A:34 0B:EF 0C:21 0F:00 00:00
2014-06-12 16:27:10 battery ok
2014-06-12 16:27:10 humidity 51
2014-06-12 16:27:10 state T: 26.5 H: 51
2014-06-12 16:27:10 temperature 26.5
Helper:
cSnd 0134EF2125FA260103
mId 003D
peerIDsRaw ,00000000
rxType 132
Io:
newChn +25FA26,00,01,00
nextSend 1402583230.94533
rxt 0
p:
25FA26
00
01
00
Mrssi:
mNo 04
Io:
HMLANGW -38
Prt:
bErr 0
sProc 0
Rspwait:
Q:
qReqConf
qReqStat
Role:
chn 1
dev 1
Rssi:
At_hmlangw:
avg -41.1
cnt 20
lst -40
max -37
min -51
Shadowreg:
Attributes:
IODev HMLANGW
actCycle 000:10
actStatus alive
autoReadReg 4_reqStatus
expert 2_full
firmware 1.3
model HM-WDS10-TH-O
peerIDs 00000000,
room CUL_HM
serialNr LEQ0029731
subType THSensor
... nur mal so als temporärer Workaround. War sowohl bei 3 Thermostaten (FW 1.2) als auch bei dem Außenthermometer so.
Hallo peterk_de
dankechön für den Hinweis, hat prima geholfen
Gruss tagedieb
Hatte bisher immer regelmaessig, im Abstand von ein oder zwei Wochen "update" getippt und dann "shutdown restart". Heute war es auch mal wieder soweit und prompt bin ich genau in die hier beschriebenen Probleme gelaufen. Von diesem thread wusste ich da noch nichts aber ich konnte mir selbst helfen, habe einfach das backup restored und alles war wieder gut.
Doch nun die Frage: Was ist eigentlich die richtige Vorgehensweise, wenn man nicht unbedingt immer das neueste haben will sondern immer nur von einem stabilen, konsistenten, und getesteten Stand auf den naechsten stabilen, konsistenten, und getesteten Stand hoch gehen moechte? Ich vermute mal, einfach "update" in die commandline des Web UI eintippen, ist definitiv der falsche Weg. Aber was stattdessen?
Immer erst Nachmittags oder Abends updaten ;). Vorher hier rein schauen und die Beiträge querlesen (am besten die ungelesenen Beiträge durchgehen). So mache ich es auf dem Produktivsystem.
Zitat von: marvin78 am 12 Juni 2014, 20:37:11
Immer erst Nachmittags oder Abends updaten ;). Vorher hier rein schauen und die Beiträge querlesen (am besten die ungelesenen Beiträge durchgehen). So mache ich es auf dem Produktivsystem.
Sehe ich ähnlich, lieber nicht morgens updaten ;) Bin auch drauf "reingefallen". Aber hey, auf der anderen Seite bin ich echt froh, dass Martin sich darum immer kümmert! Es ist ja schliesslich seine Freizeit. Schade, dass es im Moment leider nur den "Development" Zweig gibt und noch keinen Stable. Aber ich bin schon froh, dass es FHEM überhaupt gibt :)
VG,
Boris
Jeder, der momentan Probleme mit Homematic-Devices (und in den letzten 2 Tagen ein FHEM-Update gemacht) hat, kann einfach Abhilfe schaffen, indem der die 10_CUL_HM.pm von hier (http://sourceforge.net/p/fhem/code/6096/tree/trunk/fhem/FHEM/10_CUL_HM.pm?format=raw) herunterlädt und in seinem FHEM-Ordner die neue, kaputte Version durch diese ersetzt. Danach den FHEM-Neustart nicht vergessen.
Alle anderen seien gewarnt: Kein Update machen, bevor Martin den Fehler nicht behoben hat.
Zitat von: tinyfhem am 12 Juni 2014, 20:31:23
Doch nun die Frage: Was ist eigentlich die richtige Vorgehensweise, wenn man nicht unbedingt immer das neueste haben will
Drei Systeme:
- Entwicklungssystem - da wird gebastelt und da werden Updates zuerst eingespielt.
- Testsystem / QS-System - da wird alles, was im Entwicklungssystem entstanden ist und dort funktioniert, eingespielt und getestet.
- Produktivsystem - da wird alles, was im QS-System erfolgreich getestet wurde, eingespielt und in den Produktivbetrieb übernommen.
... meine Variante ist, da ich kein zusätzliches Testsystem habe, nur updaten wenn etwas nicht so funktioniert wie ich will, und ich danach noch mindestens 2 Stunden Freizeit zum Testen und Problembeheben habe ;-) Denn sowas wie einen Stable-Branch hat FHEM ja nicht. Wenn man bedenkt, wie oft Martin updatet und was für einen gigantischen Zoo an Geräten er hier alleine wuppt (kein anderes Open-Source-Automationstool hat diesen krassen Homematic-Support!), finde ich, dass dafür recht selten soetwas passiert - liegt aber nunmal in der Natur der Dinge, dass es vorkommt.
Zitat von: betateilchen am 12 Juni 2014, 20:55:59
Drei Systeme:
- Entwicklungssystem - da wird gebastelt und da werden Updates zuerst eingespielt.
- Testsystem / QS-System - da wird alles, was im Entwicklungssystem entstanden ist und dort funktioniert, eingespielt und getestet.
- Produktivsystem - da wird alles, was im QS-System erfolgreich getestet wurde, eingespielt und in den Produktivbetrieb übernommen.
sollte man nicht lieber den updatemechanismus von fhem überdenken? updates sollen etwas verbessern und nicht verschlechtern. gerade bei hm ist das in der zeit wo ich fhem betreibe das 3. oder 4. mal das nach einem update im bereich hm nichts mehr sauber läuft (auch bei anderen modulen aber hm trifft mich zum beispiel am meisten wenn nicht gerade hochsommer ist). bitte auch nicht falsch verstehen, martin leistet tolle arbeit und steckt offensichtlich sehr viel zeit hier rein. man kann/sollte den usern nicht 2-3 systeme zumuten um sicher zu sein (klar ist es recht einfach zurück zu springen wenn man weiss wie).
etwas in richtung stabel und nightly updates wären doch nicht schlecht oder? wenn die nighly-tester keine fehler melden nach x tagen gehts ins stable-update mir rein. per "globaler varibale" kann sich der user dann aussuchen ob er stabil oder aktuell sein will.
Das wirst du nicht hinbekommen (zu wenig Tester mit allen möglichen Geräten - da kann es für manche Entwicklungen ewig dauern, bis sie endlich im stable-Zweig sind). Ich denke auch nicht, dass man 2-3 Systeme braucht um sicher zu sein. Meine Methode mit dem Update am Nachmittag oder Abend, erst nachdem ich mich hier grob durchgelesen habe, ist schon recht sicher und ich hatte bspw. noch nie ein Problem mit einem nicht mehr funktionierenden System, weil ein Modul gesponnen hat.
FHEM ist kein Consumer-System. Das muss man wissen, wenn man sich darauf einlässt. Und unter dem Gesichtspunkt sollte man schon jeden User von FHEM zutrauen, das mit den Updates selbst ganz günstig zu entscheiden.
Zitat von: marvin78 am 12 Juni 2014, 21:43:16
Das wirst du nicht hinbekommen (zu wenig Tester mit allen möglichen Geräten - da kann es für manche Entwicklungen ewig dauern, bis sie endlich im stable-Zweig sind). Ich denke auch nicht, dass man 2-3 Systeme braucht um sicher zu sein. zu entscheiden.
sehe ich für mich auch so, habe auch mehrere system (allein wenn mal hardware ausfällt)
Zitat von: marvin78 am 12 Juni 2014, 21:43:16
FHEM ist kein Consumer-System. Das muss man wissen, wenn man sich darauf einlässt.
wie so viele andere opensource-projekte auch, das sollte nicht als "ausrede" angeführt werden.
ich finde nur der anspruch eines users an software darf es durchaus sein etwas stabiles zu bekommen und nicht bei jedem update bangen zu müssen (das wirkt sich auch positiv auf verbreitung und denke ich auch dann mehr support der entwickler durch zb spenden, ob nun sachen oder geld, aus).
Das wirst du nicht hinbekommen (zu wenig Tester mit allen möglichen Geräten - da kann es für manche Entwicklungen ewig dauern, sollte man solche kaum genutzten module evtl. nur in contrib und entsprechendem hinweis verteilen
Zitat von: chris1284 am 12 Juni 2014, 21:34:30
sollte man nicht lieber den updatemechanismus von fhem überdenken? updates sollen etwas verbessern und nicht verschlechtern.
Ihr nutzt den Entwicklungstrunk ! Es ist nicht den Entwicklern anzulasten, wenn Ihr meint diesen direkt produktiv einzusetzen zu müssen. Wenn man bedenkt, was gerade bei HM nahezu täglich an Erweiterungen eingebaut wird (und hier kann man Martin gar nicht genug danken !!!!) ist es fast unglaublich wie stabil die Entwicklungsversion läuft ! Wem das Risiko zu hoch ist, der muss halt mit dem offiziellen Stable Release vorlieb nehmen ! Wer jedoch immer am Puls der Zeit sein möchte, der muss damit leben, wenn sich mal ein Bug einschleicht und schlicht in der Lage sein, auf die alte Version zurückzurollen, oder bereits von betateilchen erwähnt - und das ist der Mindeststandard im realen IT Betrieb - sich eine E/K/P Landschaft gönnen ! That's it ! Das Forum ist nicht zuletzt dafür da, die Fehler aufzudecken, die sich ggf. eingeschlichen haben, damit die Entwickler sie fixen können ....
Es ist doch ohnehin niemand dazu gezwungen, täglich jedes verfügbare Update einzuspielen.
Und wem 30 Euro Hardwarekosten für ein zweites System, um Updates vor der Übernahme in die Produktivumgebung zu testen, zuviel Geld sind, sollte sich nicht beschweren, wenn er durch ein nicht funktionierendes Update seine Installation lahmlegt. Bei mir kommt schon lange kein Update mehr direkt in das Produktivsystem, nicht nur aus den Erfahrungen mit Homematic, sondern auch aus meiner Sicht als Entwickler und aus den Erfahrungen mit meinen eigenen Modulen. Der "reine" Nutzer, der keine eigenen Entwicklungsarbeiten leistet, braucht vermutlich keine drei Systeme, aber zwei sollten es schon sein, wenn man sein fhem so weit ausgebaut hat, dass man auf einen zuverlässigen Betrieb angewiesen ist.
Der Vorschlag, "wenig benötigte Module" nach contrib zu verlegen, bringt auch nicht viel weiter, denn contrib wird beim Update überhaupt nicht berücksichtigt - und das ist auch gut so.
Ich habe eben ausnahmsweise etwas getan, was ich sonst eigentlich nie mache:
Um zu verhindern, dass sich andere User durch ein Update auf die defekte 10_CUL_HM.pm ihr fhem lahmlegen, habe ich das Modul auf die vorherige Version 6096 zurückgesetzt, da nach drei Tagen noch keinerlei Reaktion seitens der Entwicklung kam. (Natürlich darf sich jeder irgendwann eine Auszeit nehmen.)
Guten Morgen ihr Lieben, bei mir geht nichts mehr keine Ahnung. Habe die 10_CUL_HM von Oben mit der von mir Überschrieben nichts geht mehr. Ich weiß nicht mehr was ich machen soll, habe auch schon ein altes Backup eingespielt nichts!
Zitat von: justl82 am 13 Juni 2014, 07:04:31
Guten Morgen ihr Lieben, bei mir geht nichts mehr keine Ahnung. Habe die 10_CUL_HM von Oben mit der von mir Überschrieben nichts geht mehr. Ich weiß nicht mehr was ich machen soll, habe auch schon ein altes Backup eingespielt nichts!
So etwas steht auch in der FHEM log Cannot init /dev/ttyACM0, ignoring it
Wenn ich in FHEM usb scan eingebe kommt das " ### ttyACM0: checking if it is a CUL
cannot open the device ", warum kann der den nicht öffnen?
Schon mal neun kompletten Neustart gemacht?
Gesendet von meinem Nexus 4 mit Tapatalk
Zitat von: strauch am 13 Juni 2014, 08:00:03
Schon mal neun kompletten Neustart gemacht?
Gesendet von meinem Nexus 4 mit Tapatalk
Der CUL ist jetzt da aber an einem Geräte immernoch MISSING ACK.
missing-ack Problem sollte mit 6105 erledigt sein. Falls nicht, bitte noch einmal melden
Hallo zusammen,
also ich bin mit meinem System auch in dieses Problem gelaufen und mit den Einträgen in diesem Forum war auch schnell ein Workaround gefunden. Aber das kann nun mal bei einer so Umfangreichen Lösung wie FHEM passieren.
Ich persönlich arbeite im IT Umfeld großer Banken und Versicherungen und habe auch in diesem Umfeld bisher noch keine derartig großartige Community mit dem Drang nach Entwicklung und großartigem Support erlebt. Da sind viele große kommerzielle Produkte nicht so gut unterstützt.
Ich bin zwar kein Entwickler, aber mit ein wenig Einlesen innerhalb des Forums und Fhem-Wiki und dem Support hier im Forum lassen sich die Probleme rasch beheben.
Ich möchte mich deshalb hier an dieser Stelle für die Gesamtlösung FHEM bedanken.
Großartige Arbeit Leute
Zitat von: martinp876 am 13 Juni 2014, 08:33:41
missing-ack Problem sollte mit 6105 erledigt sein. Falls nicht, bitte noch einmal melden
Wie meinst du das? Wie bekomme ich 6105 drauf?
Morgen ein update machen oder selbst aus dem svn ziehen.
Gesendet von meinem Nexus 4 mit Tapatalk
Zitat von: strauch am 13 Juni 2014, 08:53:04
Morgen ein update machen oder selbst aus dem svn ziehen.
Gesendet von meinem Nexus 4 mit Tapatalk
Selbst aus svn ziehen was meinst du damit?
Der Quellcode von fhem liegt auf SourceForge da kannst du es dir herunterladen.
Gesendet von meinem Nexus 4 mit Tapatalk
Hallo,
auf der Übersichtsseite des Forums gibt es unten einen Link dahin.
Gruß Christoph
@justl82 .... etwas mehr "Eigeninitiative" wäre wünschenswert. Also erst im Forum suchen und dann posten. ;)
Ok ich werde es mal Testen und dann Berichten.
Muß ich da nur die 10_CUL_HM.pm ersetzen?
Ja!
So sieht besser aus nur sind meine ganzen Geräte weg nur die logs werden noch geschrieben. Es kommt jetzt im Logfile:
2014.06.13 09:59:59 0: ERROR: Cannot autoload CUL_HM
2014.06.13 09:59:59 3: CUL1: Unknown code A0F0E861022B62F0000000A24E60E0056::-64:CUL1, help me!
2014.06.13 10:00:06 1: reload: Error:Modul 10_CUL_HM deactivated:
Can't modify constant item in predecrement (--) at ./FHEM/10_CUL_HM.pm line 2, near "Server:"
syntax error at ./FHEM/10_CUL_HM.pm line 2, near "Server:"
Unknown regexp modifier "/n" at ./FHEM/10_CUL_HM.pm line 9925, at end of line
Unknown regexp modifier "/n" at ./FHEM/10_CUL_HM.pm line 9926, at end of line
Unknown regexp modifier "/n" at ./FHEM/10_CUL_HM.pm line 9926, at end of line
Unknown regexp modifier "/n" at ./FHEM/10_CUL_HM.pm line 9927, at end of line
Unknown regexp modifier "/n" at ./FHEM/10_CUL_HM.pm line 9927, at end of line
Unknown regexp modifier "/n" at ./FHEM/10_CUL_HM.pm line 9928, at end of line
Unknown regexp modifier "/n" at ./FHEM/10_CUL_HM.pm line 9928, at end of line
Unknown regexp modifier "/n" at ./FHEM/10_CUL_HM.pm line 9929, at end of line
./FHEM/10_CUL_HM.pm has too many errors.
Was ist das nur wieder?
hast du korrekt downgeloaded?
Das file sollte nicht mehr als 9491 zeilen haben.
nutze den link zum downloaden in svn, nichts anderes
Gruss Martin
Hallo,
das ist der direkte Link http://sourceforge.net/p/fhem/code/HEAD/tree/trunk/fhem/FHEM/10_CUL_HM.pm und dann oben links "Download this File" nehmen.
Gruß Christoph
Alles so gemacht ich bekomme zwar Werte aber trotzdem noch Missing ACK.
FHEM-Log:
2014.06.13 10:30:17 1: /dev/ttyACM0 disconnected, waiting to reappear
2014.06.13 10:30:18 3: Setting CUL1 baudrate to 9600
2014.06.13 10:30:18 1: /dev/ttyACM0 reappeared (CUL1)
2014.06.13 10:30:19 3: CUL1: Possible commands: BCFiAZEGMKRTVWXefmltux
2014.06.13 10:30:20 3: CUL_HM set Heizkoerper_Kueche getConfig
2014.06.13 10:35:15 1: /dev/ttyACM0 disconnected, waiting to reappear
2014.06.13 10:35:16 3: Setting CUL1 baudrate to 9600
2014.06.13 10:35:16 1: /dev/ttyACM0 reappeared (CUL1)
2014.06.13 10:35:16 3: CUL1: Possible commands: BCFiAZEGMKRTVWXefmltux
2014.06.13 10:37:29 1: /dev/ttyACM0 disconnected, waiting to reappear
2014.06.13 10:37:29 3: Setting CUL1 baudrate to 9600
2014.06.13 10:37:29 1: /dev/ttyACM0 reappeared (CUL1)
2014.06.13 10:37:29 3: CUL1: Possible commands: BCFiAZEGMKRTVWXefmltux
2014.06.13 12:30:54 3: CUL_HM set WK.Waschmaschine_Betrieb on
2014.06.13 12:30:56 1: /dev/ttyACM0 disconnected, waiting to reappear
2014.06.13 12:30:56 3: Setting CUL1 baudrate to 9600
2014.06.13 12:30:56 1: /dev/ttyACM0 reappeared (CUL1)
2014.06.13 12:30:56 3: CUL1: Possible commands: BCFiAZEGMKRTVWXefmltux
2014.06.13 12:30:59 1: /dev/ttyACM0 disconnected, waiting to reappear
2014.06.13 12:31:00 3: Setting CUL1 baudrate to 9600
2014.06.13 12:31:00 1: /dev/ttyACM0 reappeared (CUL1)
2014.06.13 12:31:00 3: CUL1: Possible commands: BCFiAZEGMKRTVWXefmltux
2014.06.13 12:31:13 1: /dev/ttyACM0 disconnected, waiting to reappear
2014.06.13 12:31:14 3: Setting CUL1 baudrate to 9600
2014.06.13 12:31:14 1: /dev/ttyACM0 reappeared (CUL1)
2014.06.13 12:31:14 3: CUL1: Possible commands: BCFiAZEGMKRTVWXefmltux
2014.06.13 12:31:53 3: CUL_HM set WK.Waschmaschine_Betrieb off
2014.06.13 12:31:55 1: /dev/ttyACM0 disconnected, waiting to reappear
2014.06.13 12:31:56 3: Setting CUL1 baudrate to 9600
2014.06.13 12:31:56 1: /dev/ttyACM0 reappeared (CUL1)
2014.06.13 12:31:56 3: CUL1: Possible commands: BCFiAZEGMKRTVWXefmltux
2014.06.13 12:31:59 3: CUL_HM set Heizkoerper_Kueche getConfig
2014.06.13 12:31:59 3: CUL_HM set Heizkoerper_Wohnzimmer getConfig
2014.06.13 12:32:00 1: /dev/ttyACM0 disconnected, waiting to reappear
2014.06.13 12:32:01 3: Setting CUL1 baudrate to 9600
2014.06.13 12:32:01 1: /dev/ttyACM0 reappeared (CUL1)
2014.06.13 12:32:01 3: CUL1: Possible commands: BCFiAZEGMKRTVWXefmltux
2014.06.13 12:32:06 1: /dev/ttyACM0 disconnected, waiting to reappear
2014.06.13 12:32:06 3: Setting CUL1 baudrate to 9600
2014.06.13 12:32:06 1: /dev/ttyACM0 reappeared (CUL1)
2014.06.13 12:32:06 3: CUL1: Possible commands: BCFiAZEGMKRTVWXefmltux
2014.06.13 12:32:11 1: /dev/ttyACM0 disconnected, waiting to reappear
2014.06.13 12:32:11 3: Setting CUL1 baudrate to 9600
2014.06.13 12:32:11 1: /dev/ttyACM0 reappeared (CUL1)
2014.06.13 12:32:11 3: CUL1: Possible commands: BCFiAZEGMKRTVWXefmltux
hm - deine CUL reseted dauernd. Aber in den Logs kann ich die messages nicht sehen - sind die bei der CUL eingeschaltet?
Zitat von: martinp876 am 13 Juni 2014, 13:37:56
hm - deine CUL reseted dauernd. Aber in den Logs kann ich die messages nicht sehen - sind die bei der CUL eingeschaltet?
Wie geht das?
Als ich noch einen RasPi benutzt habe hat alles funktioniert, jetzt habe ich einen Intel Nuc mit Ubuntu 14.04, daran kann es nicht liegen oder?
Hallo,
wie oder woher hast Du denn die Treiber für den CUL - passen die zu Deinem System ?
Gruß Christoph
Zitat von: Bennemannc am 13 Juni 2014, 14:27:34
Hallo,
wie oder woher hast Du denn die Treiber für den CUL - passen die zu Deinem System ?
Gruß Christoph
Na von der culfw Seite, woanders gibt es doch keinen oder doch? Ist Linux nicht Linux?
Hallo,
nein Linux ist nicht Linux - je nach Hardware Intel, Arm, .... verschiedene Kernel Versionen, 32 oder 64 Bit.
Linux kann das alles aber Du wirst keine Arm Kernel auf ein 64 Bit Intel System installieren können. Normalerweise gibt es beim Hersteller die Quellen für ein (Kernel) Modul, es muss aber ggf. neu compiliert werden, damit es zu dem Kernel auf Deinem System passt. Dazu werden Teile der Kernelquelle, ein gcc Compiler, make ... und noch einige andere Pakete benötigt. Wenn Du ein Kernelmodul einfach so dazu packst, sind Probleme vorprogrammiert.
Gruß Christoph
Also muss ich die 32 Bit Version installieren?
Gesendet von meinem GT-I9100 mit Tapatalk
Gehe mal auf www.meintechblog.de der hat es auch auf dem NUC laufen.
Gesendet von meinem GT-I9100 mit Tapatalk
Hallo!
Mit neuer Version immer noch Fehler im log:
2014.06.13 21:53:23 3: HMLAN1: Unknown code A0ED78202193B68193858010100003D::-46:HMLAN1, help me!
aber keine Missing Ack, noch zur Info bei im System ein HMLAN/Cubietruck!
Mfg Steffen
@ Steffen
Guck mal hier:
http://forum.fhem.de/index.php/topic,24370.0.html
VG
Frank
Zitat von: franky08 am 13 Juni 2014, 22:25:49
@ Steffen
Guck mal hier:
http://forum.fhem.de/index.php/topic,24370.0.html
VG
Frank
Da lese ich auch mit aber habe wohl da die Lösung überlesen, kannst du mir vielleicht sagen wo das Problem genau liegt??
MFG Steffen
Zitat von betateilchen:
ZitatFolgende Versionskombination funktioniert fehlerfrei:
00_HMLAN = 6008
10_CUL_HM = 6054
HMConfig = 6044
wobei ich jetzt nicht näher gesucht habe, welches Modul letztendlich wirklich für den Fehler verantwortlich ist.
VG
Frank
P.S. Warte mit einem update bis morgen, dann dürfte alles wieder OK sein, Martin arbeitet dran. Oder lade dir die neue
10_CUL_HM aus dem SVN
http://sourceforge.net/p/fhem/code/HEAD/tree/trunk/fhem/FHEM/10_CUL_HM.pm
Habe ein HMLAN
Nach Update heute ist zwar MISSING ACK Geschichte aber beim Anlernen neuer Aktoren stürzt fehm immer noch mitten drin ab.
Vielleicht doch auch ein Problem mit 00_HMLAN?
@betateilchen ... kannst Du mir die
00_HMLAN = 6008
10_CUL_HM = 6054
HMConfig = 6044
vielleicht zur Verfügung stellen? Mein Update war nach einer viel älteren Version und da ist der Sprung offensichtlich zu groß und mach andere Schwierigkeiten.
Stefan
Du kannst dir die Versionen zB hier herunterladen:
http://sourceforge.net/p/fhem/code/HEAD/tree/trunk/fhem/FHEM/
Einfach eine Datei anklicken und dann oben auf "History" drücken.
Ja glaubt man das. Wie oft war ich schon auf der Seite und das mit der History hab ich übersehen ::)
Danke - so einfach :)
Ich möchte an dieser Stelle noch erwähnen, dass es bei mir selbst beim Zurückspielen der genannten Versionsnummern von Sourceforge NICHT wieder funktioniert hat.
Es scheint also noch andere Änderungen innerhalb von FHEM zu geben, die zu den Problemen mit Homematic führen.
Es ist mir nach wie vor nicht möglich, einen Türgong zu pairen, es kommt zu den beschriebenen Fehlern.
Auf meinem Produktivsystem, das ich zuletzt vor einigen Wochen aktualisiert habe, funktioniert es dagegen einwandfrei.
Ich habe dann,
- Test-HMLAN ins Produktivsystem eingebunden, dort Türgong angelernt
- autocreate-Einträge per Copy-Paste ins Testsystem kopiert
- HMLAN wieder im Testsystem aktiviert
Selbst mit diesem gepairten Geräte-Paar schafft es das aktuelleste FHEM nicht mehr, den Türgong zu aktivieren.
Zurück ins Produktivsystem geht es sofort wieder.
Da ich das Experimentieren Leid bin habe ich meine Produktiv-SD auf die Test-SD mit Win32DiskImager geclont.
So habe ich jetzt auch gleich ein Backup meines Produktivsystems auf der Platte.
Ich hoffe sehr, dass auch die aktuellen Versionen bald wieder so zuverlässig sind wie früher :-(
Viele Grüße,
Heiko
Ich habe eben ein update gemacht und leider erst danach dies hier gesehen. ::)
Aber es scheint jetzt wieder alles normal zu funktionieren. Meine Versionen sind:
# $Id: 10_CUL_HM.pm 6110 2014-06-14 11:58:49Z
# $Id: 00_HMLAN.pm 6069 2014-06-05 14:21:43Z
# $Id: HMConfig.pm 6068 2014-06-05 13:56:04Z
Habe ich nur Glück oder kann jemand offiziell Entwarnung geben?
ist gelöst
Danke. Also beides: Glück und Entwarnung. ;D
Zitat von: heikoh81 am 15 Juni 2014, 17:09:47
Ich möchte an dieser Stelle noch erwähnen, dass es bei mir selbst beim Zurückspielen der genannten Versionsnummern von Sourceforge NICHT wieder funktioniert hat.
Es scheint also noch andere Änderungen innerhalb von FHEM zu geben, die zu den Problemen mit Homematic führen.
Ich habe mich auch zu früh gefreut. Mit dem gestrigen update gab's zwar keinen Absturz aber Anlernen von Schaltaktoren hat nicht funktioniert. Aus Zeitmangel und weil ich kein Testsystem habe bin ich erst mal zurück auf Stable.
wenn du es noch einmal probieren willst schicke die logs (rohmessages) wenn du mit der neun Version anlernst
Hi zusammen,
nach dem Update ging fast alles nur bei meinem Bewegungssensor hatte ich die ganze Zeit einen:
Sensor Activity: dead
Sensor Activity: unknown
Sensor Activity: unknown
Sensor Activity: unknown
Sensor Activity: unknown
Nachdem ich das ganze System resetet habe und zusätzlich beim Bewegungssensor die Batterien entfernt habe (zum reset) ging wieder alles.
Vielleicht braucht jemand die Info.
Super update.
Vielen Dank dafür.
Zitat von: martinp876 am 16 Juni 2014, 08:48:04
wenn du es noch einmal probieren willst schicke die logs (rohmessages) wenn du mit der neun Version anlernst
Hab's nochmal probiert (update von heute direkt von 5.5 stable) . Log nach anlernen:
2014.06.19 18:10:50 3: CUL_HM pair: CUL_HM_HM_SEC_SFA_SM_xx switch, model HM-SEC-SFA-SM serialNr LEQXXXXX
2014.06.19 18:10:50 3: CUL_HM set CUL_HM_HM_SEC_SFA_SM_xx getConfig
2014.06.19 18:10:50 4: eventTypes: CUL_HM CUL_HM_HM_SEC_SFA_SM_xx D-firmware: 1.3 -> D-firmware: .*
2014.06.19 18:10:50 4: eventTypes: CUL_HM CUL_HM_HM_SEC_SFA_SM_xx D-serialNr: LExxxxxx -> D-serialNr: LEXXXXX
2014.06.19 18:10:50 4: eventTypes: CUL_HM CUL_HM_HM_SEC_SFA_SM_xx R-pairCentral: set_0x25748F -> R-pairCentral: set_.*x25748F
2014.06.19 18:10:50 4: eventTypes: CUL_HM CUL_HM_HM_SEC_SFA_SM_xx R-intKeyVisib: set_invisib -> R-intKeyVisib: set_invisib
2014.06.19 18:10:50 4: eventTypes: CUL_HM CUL_HM_HM_SEC_SFA_SM_xx CMDs_pending -> CMDs_pending
22014.06.19 18:10:50 4: eventTypes: CUL_HM CUL_HM_HM_SEC_SFA_SM_xx state: CMDs_pending -> state: CMDs_pending
2014.06.19 18:10:51 4: CUL_HM CUL_HM_HM_SEC_SFA_SM_xx dupe: dont process
2014.06.19 18:10:52 4: eventTypes: CUL_HM CUL_HM_HM_SEC_SFA_SM_xx R-pairCentral: 0x25748F -> R-pairCentral: 0x25748F
2014.06.19 18:10:52 4: eventTypes: CUL_HM CUL_HM_HM_SEC_SFA_SM_xx R-intKeyVisib: invisib -> R-intKeyVisib: invisib
2014.06.19 18:10:52 4: eventTypes: CUL_HM CUL_HM_HM_SEC_SFA_SM_xx R-transmDevTryMax: 6 -> R-transmDevTryMax: .*
2014.06.19 18:10:52 4: eventTypes: CUL_HM CUL_HM_HM_SEC_SFA_SM_xx R-sabotageMsg: on -> R-sabotageMsg: on
2014.06.19 18:10:52 4: eventTypes: CUL_HM CUL_HM_HM_SEC_SFA_SM_xx R-cyclicInfoMsg: on -> R-cyclicInfoMsg: on
2014.06.19 18:10:52 4: CUL_HM CUL_HM_HM_SEC_SFA_SM_xx dupe: dont process
2014.06.19 18:10:52 4: eventTypes: CUL_HM CUL_HM_HM_SEC_SFA_SM_xx_Siren R-transmitTryMax: 6 -> R-transmitTryMax: .*
2014.06.19 18:10:52 4: eventTypes: CUL_HM CUL_HM_HM_SEC_SFA_SM_xx_Siren R-sign: off -> R-sign: off
2014.06.19 18:10:52 4: eventTypes: CUL_HM CUL_HM_HM_SEC_SFA_SM_x_Siren R-transmitTryMax: 6 -> R-transmitTryMax: .*
2014.06.19 18:10:53 4: CUL_HM CUL_HM_HM_SEC_SFA_SM_xx dupe: dont process
2014.06.19 18:10:54 4: eventTypes: CUL_HM CUL_HM_HM_SEC_SFA_SM_xx_Flash R-transmitTryMax: 6 -> R-transmitTryMax: .*
2014.06.19 18:10:54 4: eventTypes: CUL_HM CUL_HM_HM_SEC_SFA_SM_xx_Flash R-sign: off -> R-sign: off
2014.06.19 18:10:54 4: eventTypes: CUL_HM CUL_HM_HM_SEC_SFA_SM_x_Flash R-transmitTryMax: 6 -> R-transmitTryMax: .*
2014.06.19 18:10:54 4: eventTypes: CUL_HM CUL_HM_HM_SEC_SFA_SM_xx CMDs_done -> CMDs_done
2014.06.19 18:10:54 4: eventTypes: CUL_HM CUL_HM_HM_SEC_SFA_SM_x state: CMDs_done -> state: CMDs_done
2014.06.19 18:10:54 4: CUL_HM CUL_HM_HM_SEC_SFA_SM_xx dupe: dont process
...
in der cfg ist dann aber nur:
define CUL_HM_HM_SEC_SFA_SM_xx CUL_HM xx
attr CUL_HM_HM_SEC_SFA_SM_xx room CUL_HM
define FileLog_CUL_HM_HM_SEC_SFA_SM_xx FileLog ./log/CUL_HM_HM_SEC_SFA_SM_xx-%Y.log CUL_HM_HM_SEC_SFA_SM_xx
attr FileLog_CUL_HM_HM_SEC_SFA_SM_xx logtype text
attr FileLog_CUL_HM_HM_SEC_SFA_SM_xx room CUL_HM
Das Gerät ist zwar verwendbar und löst auch Events aus aber die Konfiguration ist halt unvollständig und muss manuell bearbeitet werden.
ich wollte rohmessages
http://www.fhemwiki.de/wiki/Homematic_Nachrichten_sniffen
hier sehe ich nur events.
habe Dir die Rohmessages per eMail geschickt ...
Gruß
Stefan
kannst du noch einmal detailiert erklären , was nicht funktioniert?
Das Device ist korrekt angelernt worden. Es wird alles auch gelesen...
Zitataber die Konfiguration ist halt unvollständig und muss manuell bearbeitet werden.
was fehlt genau?
Zitatwas fehlt genau?
wie gesagt - nur das ist da:
define CUL_HM_HM_SEC_SFA_SM_xx CUL_HM xx
attr CUL_HM_HM_SEC_SFA_SM_xx room CUL_HM
define FileLog_CUL_HM_HM_SEC_SFA_SM_xx FileLog ./log/CUL_HM_HM_SEC_SFA_SM_xx-%Y.log CUL_HM_HM_SEC_SFA_SM_xx
attr FileLog_CUL_HM_HM_SEC_SFA_SM_xx logtype text
attr FileLog_CUL_HM_HM_SEC_SFA_SM_xx room CUL_HMVorher (und mit der 5.5-stable) sah das so aus, mit dem gleichen Aktor (nach rename natürlich):
define BlitzSirene CUL_HM xxxxx
attr BlitzSirene .devInfo 820100
attr BlitzSirene .stc 10
attr BlitzSirene expert 2_full
attr BlitzSirene firmware 1.3
attr BlitzSirene model HM-SEC-SFA-SM
attr BlitzSirene peerIDs
attr BlitzSirene room CUL_HM
attr BlitzSirene serialNr LEXXXXX
attr BlitzSirene subType switch
attr BlitzSirene webCmd getConfig
define FileLog_BlitzSirene FileLog ./log/BlitzSirene-%Y.log BlitzSirene
attr FileLog_BlitzSirene logtype text
attr FileLog_BlitzSirene room CUL_HM
define Sirene CUL_HM XXXXX01
attr Sirene expert
attr Sirene model HM-SEC-SFA-SM
attr Sirene peerIDs
attr Sirene room Alarm
attr Sirene webCmd toggle:on:off:statusRequest
define FileLog_Sirene FileLog ./log/Sirene-%Y.log Sirene
attr FileLog_Sirene logtype text
attr FileLog_Sirene room CUL_HM
define Blitz CUL_HM xxxxx02
attr Blitz expert
attr Blitz model HM-SEC-SFA-SM
attr Blitz peerIDs
attr Blitz room Alarm
attr Blitz webCmd toggle:on:off:statusRequest
define FileLog_Blitz FileLog ./log/Blitz-%Y.log Blitz
attr FileLog_Blitz logtype text
attr FileLog_Blitz room CUL_HM
also die Details der Konfiguration fehlen ebenso wir die Definition der zugehörigen Kanäle.
Hallo Martin,
bei mir macht sich der RPI mit COC selbständig... nach dem Update wird jede Sekunde folgendes ins Log geschrieben:
2014.06.18 22:46:04 3: COC_RPi: Unknown code A0CF386701AC16F00000000DB3C::-74.5:COC_RPi, help me!
2014.06.18 22:46:04 3: COC_RPi: Unknown code A0CF3C6701AC16F00000000DB3C::-88:COC_RPi, help me!
2014.06.18 22:46:04 3: COC_RPi: Unknown code A0C46A0111F7D571D4763800203::-97.5:COC_RPi, help me!
2014.06.18 22:46:04 3: COC_RPi: Unknown code A124680021D47631F7D57010203002E00122E7F::-98:COC_RPi, help me!
2014.06.18 22:46:04 3: COC_RPi: Unknown code A0E6A82021A89DE1A7DA6010100002E::-100:COC_RPi, help me!
2014.06.18 22:46:04 3: COC_RPi: Unknown code A0C4FA0111F7D571D4763800401::-97:COC_RPi, help me!
2014.06.18 22:46:04 3: COC_RPi: Unknown code A124F80021D47631F7D57010401002E00122E7F::-97:COC_RPi, help me!
Die Logdatei ist nach 1,5 Tagen über 5 MB groß!!
Nach dem Update funktioniert auch meine Keymatic nicht mehr vernünftig mit der Keymatic-Remote.
Bin jetzt wieder auf die alte Version zurück und alles funktioniert wieder einwandfrei.
Will heute mal versuchen herauszufinden, ob es nicht noch an etwas anderem liegt.
Viele Grüße
Dennis
Hallo zusammen,
ich hab's noch einmal getestet und es liegt definitiv an den 3 HM-Dateien
Habe das System aktualisiert mit den neusten Daten und sofort kamen wieder im Sekundentakt diese komischen Log-Einträge, dass der COC einige Codes nicht versteht.
Auszug:
2014.06.20 15:11:07 3: COC_RPi: Unknown code A0F2F86102236D80000000A60DD0E0058::-103:COC_RPi, help me!
2014.06.20 15:11:09 3: COC_RPi: Unknown code A0C7D86701FCB8900000000CF46::-97.5:COC_RPi, help me!
2014.06.20 15:11:10 3: COC_RPi: Unknown code A0C72A0111F7D571D4763800303::-98:COC_RPi, help me!
Ich habe dann nur die 3 HM-Dateien wieder eingespielt und danach lief alles wieder wie gewohnt.
Ich nutze nun wieder HM_LAN 6008, CUL_HM 6054, HMConfig 6044
Interessant war auch, dass meine Keymatic nicht mehr funktionierte.
Ich werde nun mal die einzelnen Dateien durch neue ersetzen, um das Problem weiter einzugrenzen.
dk
Hallo nochmals,
ich habe nun die Dateien durchgetestet.
Bei mir laufen jetzt
HMLAN 6069, CUL_HM 6142, HMCONFIG 6068
Ich komme also zu folgendem Ergebnis:
1. Sobald ich die aktuelle CUL_HM einspiele wird mein LOG-file vollgeschrieben.
2. Die Funktionalität meiner Tür-Sensoren bleibt jetzt erhalten.
3. Das Keymatic-Problem scheint an einer meiner Fernbedienungen zu liegen.
Warum die CUL_HM in die Logfiles schreibt kann ich nicht sagen, habe mir den Code mal angeschaut, aber irgendwie nichts auf den ersten Blick gefunden.
Viele Grüße
Dennis
Zitat von: krannich am 20 Juni 2014, 15:49:27
Warum die CUL_HM in die Logfiles schreibt kann ich nicht sagen
Weil die Funktion, solche "Fehler" zu loggen, vor kurzem neu eingebaut wurde. Der zugrundelegende Fehler existiert schon immer, wurde aber bisher nicht ins Log geschrieben.
Dazu gibt es einen eigenen Thread: http://forum.fhem.de/index.php/topic,24370.0.html
Zitat von: betateilchen am 20 Juni 2014, 16:06:14
Weil die Funktion, solche "Fehler" zu loggen, vor kurzem neu eingebaut wurde. Der zugrundelegende Fehler existiert schon immer, wurde aber bisher nicht ins Log geschrieben.
Dazu gibt es einen eigenen Thread: http://forum.fhem.de/index.php/topic,24370.0.html
Danke für den Hinweis, ich hab mir den Thread auch komplett durchgelesen... aber irgendwie gibt's da nicht so richtig eine Antwort auf das Problem. Oder habe ich etwas übersehen?
Ich befürchte, dass diese Daten von meinem Nachbarn kommen (Heizungssteuerung).
Hast Du da einen Tipp für mich?
dk
Tipp? ja, "fremde" Devices im eigenen fhem definieren und auf ignore setzen. Steht aber glaub auch in irgendeinem der beiden aktuellen Threads.
Zitat von: betateilchen am 20 Juni 2014, 17:27:00
Tipp? ja, "fremde" Devices im eigenen fhem definieren und auf ignore setzen. Steht aber glaub auch in irgendeinem der beiden aktuellen Threads.
Ja ich arbeitete gerade dran, VCCU einrichten, Geräte definieren und dann ignorieren.
Aber ist das denn sinnvoll? Ich hau mir dann doch meine config mit unnötigem Zeugs voll.
Und wenn mein Nachbar dann ein neues Gerät kauft, muss ich das ja laufend im Log überprüfen.
Kann man dieses Logging nicht einfach über ein Flag ausschalten?
Gebe zu, dass es sinnvoll ist fürs Debugging, aber im Dauerbetrieb echt übel.
Zitat von: krannich am 20 Juni 2014, 17:43:25
Aber ist das denn sinnvoll?
Ja.
Zitat von: krannich am 20 Juni 2014, 17:43:25
Kann man dieses Logging nicht einfach über ein Flag ausschalten?
nichts einfacher als das: "attr global verbose 2"
Besser fände ich aber, wenn Martin das Logging im Loglevel 4 ausgeben würde.
Zitat von: betateilchen am 20 Juni 2014, 17:49:45
nichts einfacher als das: "attr global verbose 2"
Danke für den Tipp, das hat auf jeden Fall geholfen.
Irgendwie hab ich es mit den Devices nicht hinbekommen.
Ich habe jetzt schon 20 Geräte definiert... und es tauchen immer weitere auf.
Irgendwie komisch.
Zitat von: high8 am 20 Juni 2014, 08:25:48
also die Details der Konfiguration fehlen ebenso wir die Definition der zugehörigen Kanäle.
Nachdem ich den HM-Sec-SFA nun mit einer älteren Version habe anlernen lassen ist das Problem nun für weitere Sensoren (Rauchmelder) heute mit dem aktuellen Update nicht mehr aufgetreten. Merkwürdigerweise dauert es manchmal ein paar Minuten, bis die Conf komplett ist - aber am Ende klappt jetzt alles.
Und ich bin ;D
Danke für die Unterstützung und tolle Arbeit hier!
Stefan
Ich kenne das Problem mit Missing Ack nur zu gut.
Aber kann mir jemand sagen, wo ich die Datei 10_CUL_HM.pm V6096 (oder eine neuere, die funktioniert) her bekomme und wie ich die Version meiner installierten 10_CUL_HM.pm herausfinde?
hui... fast 3 jähriges gehabt der thread :)
gibt mal version in die fhem-eingabezeile ein.
ich vermute aber mal das es mittlerweile eine neuere version dieser module gibt. ;)
Tja, fast 3 Jahre vergangen und die Probleme sind immer noch da.
Nämlich Homematic Geräte reagieren zwar auf das pairing und melden ihre Daten zurück, nehmen aber keine Befehle an, was zu einem Missing ACK führt.
Bei einigen scheint FHEM/CUL/Homematic stabil zu funktionieren. Bei anderen klappt es eben nicht und für das Grundübel gibt es bisher keine Lösung.
Verwende Raspi 3, CUL V1.66 und FHEM 5.8.
Bei der Version wurde mir bei 10_CUL_HM.pm Revision 14272 vom 13.05.17 zurückgemeldet. Aber damit ist mir zunächst auch nicht weitergeholfen.
Das siehst du leider falsch. Es ist eher so, dass bei den allermeisten Homematic problemlos funktioniert und nur ganz wenige Probleme haben, die in der Regel auf die individuelle Infrastruktur zurückzuführen sind. Es gibt kein Grundübel.
In Svn solltest du alle Versionen finden.
Mich interessieren alte Versionen nicht.
Wenn du ein Problem hast und es nicht beschreibst kann es keinen Support geben. Noch nicht einmal gegen Bezahlung, schon gar nicht kostenlos bei Freeware.
Missing ACK ist in keiner Weise eine Beschreibung eines Problems, nur ein Symptom.
Es ist noch nicht einmal klar ob du gepairt hast oder ob du verstanden hast, was das ist und wie man es sieht.
wie schon beschrieben, senden die Geräte beim Pairing(-versuch) ihre Daten zurück und diese werden unter CUL_HM angezeigt.
Dass offensichtlich trotzdem kein pairing stattgefunden hat ist mir schon bewusst.
Details siehe Anlage.
Es bleibt die Frage nach dem warum. Und damit ist man als Einsteiger doch ziemlich überfordert.
hast du denn das getan was da als hinweis steht? --> getconfig
und als bitte:
mach von den sachen ein "list <device>" und poste das in code-tags hier (das # )
Danke für die Antwort.
Aber ich habe getconfig nicht als Auswahloption.
Unter HMInfo configcheck kann ich folgendes bieten (habe nur noch einen Schalter angeschlossen):
configCheck done:
missing register list
HM_55425E: RegL_00.,RegL_01.
peer list incomplete. Use getConfig to read it.
incomplete: HM_55425E:
PairedTo missing/unknown
HM_55425E
Und beim list erhalte ich
Internals:
DEF 55425E
IODev CUL1
NAME HM_55425E
NOTIFYDEV global
NR 23
NTFY_ORDER 50-HM_55425E
STATE MISSING ACK
TYPE CUL_HM
protCmdDel 3
protResnd 3 last_at:2017-05-22 23:28:38
protResndFail 1 last_at:2017-05-22 23:28:43
protSnd 1 last_at:2017-05-22 23:28:28
protState CMDs_done_Errors:1
Readings:
2017-05-22 23:09:19 CommandAccepted yes
2017-05-19 16:27:32 D-firmware 2.8
2017-05-19 16:27:32 D-serialNr OEQ0031765
2017-05-22 23:12:04 RegL_00.
2017-05-22 23:09:19 deviceMsg off (to 55A450)
2017-05-22 23:09:19 level 0
2017-05-22 23:09:19 pct 0
2017-05-21 22:16:40 powerOn 2017-05-21 22:16:40
2017-05-22 23:09:19 recentStateType ack
2017-05-22 23:09:19 sabotageAttackId_ErrIoId_55A450 cnt:88
2017-05-22 23:09:19 sabotageAttack_ErrIoAttack cnt 88
2017-05-22 23:28:43 state MISSING ACK
2017-05-22 23:09:19 timedOn off
Helper:
HM_CMDNR 141
cSnd ,11F1000055425E0201C80000
dlvl 00
dlvlCmd ++A011F1000055425E0201000000
mId 0069
rxType 1
Expert:
def 1
det 0
raw 1
tpl 0
Io:
newChn +55425E,00,00,00
prefIO
rxt 0
vccu
p:
55425E
00
00
00
Mrssi:
mNo
Prt:
bErr 0
sProc 0
Q:
qReqConf 00
qReqStat 00
Role:
chn 1
dev 1
prs 1
Tmpl:
Attributes:
IODev CUL1
autoReadReg 4_reqStatus
expert 2_raw
firmware 2.8
model HM-LC-Sw1PBU-FM
room CUL_HM
serialNr OEQ0031765
subType switch
webCmd statusRequest:toggle:on:off
... also wohl kein pairing durchgeführt, obwohl eine Kommunikation zwischen CUL/FHEM und dem Device stattgefunden hat.
Eventuell auch vom Timing-Problem betroffen?
(CUL und Homematic ist keine gute Kombination / ein "echtes" Homematic IODev/Funkmodul ist definitiv besser und der "HMUART" kostet auch nicht viel: 20EUR, gut man muss ein wenig löten)
https://forum.fhem.de/index.php/topic,24436.0.html
Ansonsten einfach noch mal ganz in Ruhe:
set CUL hmPairForSec 60
dann wie in der Anleitung beschrieben die Anlernprozedur (Anlernen an Zentrale) durchführen (den Teil der Zentrale kannst du auslassen, das ist ja das pairForSec)...
Warten und evtl. noch mal den "Anlernknopf" drücken, bis in fhem die cmdsPending weg sind...
...und besser auch keine Errors bzw. Missing Acks sind.
Alternativ: clear MessageEvents und ein getConfig. Ebenfalls warten und evtl. mal den "Anlernknopf" drücken...
...bis keine cmdsPending und auch keine Error/Missing Acks sind.
Wenn du immer wieder Error bzw. Missing Acks bekommst, dann evtl. mal den Thread bzgl. "Spezial-FW" und "Spezial-Module" (link oben) verfolgen und umsteigen...
...oder (einfacher) auf ein geeignetes Funkmodul umsteigen (z.B. HMUART):
https://wiki.fhem.de/wiki/HM-MOD-RPI-PCB_HomeMatic_Funkmodul_f%C3%BCr_Raspberry_Pi
https://forum.fhem.de/index.php/topic,54511.0.html
Gruß, Joachim
2017-05-22 23:09:19 deviceMsg off (to 55A450)
ich würde behaupten, dass dein Aktor bereits gepairt ist nach -->(to 55A450)
das ist aber nicht dein Fhem , dein Fhem hat wohl die hmid F10000
pairen geht nur mit einer Zentrale!
Also bei dem Schalter Aktor macht der Cul keine Probleme
Zitatdas ist aber nicht dein Fhem , dein Fhem hat wohl die hmid F10000
pairen geht nur mit einer Zentrale!
dazu passt auch:
2017-05-22 23:09:19 sabotageAttackId_ErrIoId_55A450 cnt:88
Zitat von: fhem-hm-knecht am 23 Mai 2017, 10:11:30
2017-05-22 23:09:19 deviceMsg off (to 55A450)
ich würde behaupten, dass dein Aktor bereits gepairt ist nach -->(to 55A450)
das ist aber nicht dein Fhem , dein Fhem hat wohl die hmid F10000
pairen geht nur mit einer Zentrale!
Also bei dem Schalter Aktor macht der Cul keine Probleme
Da ist natürlich was dran...
Und ja bei einem so einfachen Schalter/Aktor sollte auch ein CUL keine Probleme haben.
Allerdings ist bei MISSING_ACK oft das Timing ein Problem und wenn dann mehrere Geräte dzukommen und evtl. mal welche mit vielen Kanälen, dann wird es mit einem CUL oft schwierig...
Gruß, Joachim
Zitat von: fhem-hm-knecht am 23 Mai 2017, 10:11:30
2017-05-22 23:09:19 deviceMsg off (to 55A450)
ich würde behaupten, dass dein Aktor bereits gepairt ist nach -->(to 55A450)
Nicht unbedingt. Quittungen werden auch an gepeerte Geräte geschickt. Das hat mein HM-LC-RGBW-WM (RGBW-Controler) heute als Quittung an den Bwegungsmelder im Wohnzimmer geschickt ("danke für die Bewegungsmitteilung, aber ich bleibe aus, weil es schon zu hell ist")
2017-05-23 09:43:41 deviceMsg off (to BewMelder2) Und die SabotageAttack könnte auch erscheinen, wenn FHEM Kommunikation erkennt mit Geräten, die ihm unbekannt sind.
Zitatdas ist aber nicht dein Fhem , dein Fhem hat wohl die hmid F10000
Das habe ich bisher nicht gefunden, wo liest Du das?
habt ihr mal einen rohmessage mitschmitt?
Vielen Dank für die interessanten Rückmeldungen.
@Joachim: Die Alternative mit einem anderen Funkmodul oder anderer FW schaue ich mir im nächsten Schritt an, aber da es wohl zuhauf zufriedene Anwender mit CUL/FHEM/Homematic gibt würde ich schon gerne die Ursache finden, warum sich dieser fu..ing Schalter nicht bewegt.
Ansonsten Step by Step:
Nach set <dev.> getconfig erhalte ich folgendes:
Internals
CUL1_MSGCNT 1
CUL1_RAWMSG A0D00A41055425E55A45006010000::-51:CUL1
CUL1_RSSI -51
CUL1_TIME 2017-05-24 22:48:55
DEF 55425E
IODev CUL1
LASTInputDev CUL1
MSGCNT 1
NAME HM_55425E
NOTIFYDEV global
NR 23
NTFY_ORDER 50-HM_55425E
STATE RESPONSE TIMEOUT:RegisterRead
TYPE CUL_HM
lastMsg No:00 - t:10 s:55425E d:55A450 06010000
protCmdDel 3
protCmdPend 2 CMDs pending
protLastRcv 2017-05-24 22:48:55
protResnd 3 last_at:2017-05-24 22:49:11
protResndFail 1 last_at:2017-05-24 22:49:16
protSnd 2 last_at:2017-05-24 23:05:37
protState CMDs_processing...
rssi_at_CUL1 max:-51 lst:-51 avg:-51 cnt:1 min:-51
Readings
CommandAccepted yes 2017-05-22 23:09:19
D-firmware 2.8 2017-05-19 16:27:32
D-serialNr OEQ0031765 2017-05-19 16:27:32
RegL_00.
deviceMsg off (to 55A450) 2017-05-24 22:48:55
level 0 2017-05-24 22:48:55
pct 0 2017-05-24 22:48:55
powerOn 2017-05-24 22:48:55 2017-05-24 22:48:55
recentStateType info 2017-05-24 22:48:55
sabotageAttackId_ErrIoId_55A450 cnt:88 2017-05-22 23:09:19
sabotageAttack_ErrIoAttack cnt 88 2017-05-22 23:09:19
state RESPONSE TIMEOUT:RegisterRead 2017-05-24 23:05:58
timedOn off 2017-05-24 22:48:55
Ein Gerät mit der SN 55A450 habe ich nicht. Könnte das auch eine Hex-Zahl sein?
Die Sache mit sabotageAttack kommt mir seltsam vor.
Das klingt nach einem Sabotage-Schalter bei einem Bewegungsmelder.
Tatsächlich habe ich einen Z-Wave Bewegungsmelder (Devolo) mit eingelegter Batterie im Schrank liegen.
Aber der Z-Wave Dongle ist nicht angeschlossen und es gibt keinen Hinweis, dass dessen SN 55A450 ist.
Weiteres folgt.
Siehe martin, sniffe die Rohmessages, ist im WIKI beschrieben. Mit den Daten kann dir martin bestimmt weiterhelfen.
VG
Frank
ZWave: gleiche Frequenz ganz anderes Protokoll, hat nichts damit zu tun...
Der Rest der dich wundert wurde schon einige Male versucht zu erläutern...
Wie lautet deine HMID?
Hattest du schon mal eine andere?
War das Gerät schon mal woanders angelernt?
hminfo definiert?
Damit lassen sich Probleme auch finden bzw. werden Unstimmigkeiten in der Konfiguration etc. aufgedeckt...
https://wiki.fhem.de/wiki/HomeMatic_HMInfo
Und besser mal genauere Infos: sniffen!
Sonst wird es schwer zu helfen...
Gruß, Joachim
Es funktioniert!
Es war keine hmID definiert.
Ich habe das Gerät und das Lofgile in FHEM gelöscht und anschließend zurückgesetzt (2x 5s Anlerntaste ...) und über set <CUL> hmPairSerial neu verbunden. Hat aber nichts geholfen.
Dazu noch viel getConfig, list u.ä und nochmal und nochmals über hmPairSerial verbunden. Hat alles nichts geholfen.
Nach einem weiteren Verbindungsversuch über set <CUL> hmPairForSec 60 (habe ich früher auch schon öfters gemacht) hat es dann funktioniert.
Ich weiß jetzt zwar immer noch nicht, was das eigentliche Problem war, außer evtl. der hmID, aber ich bin jetzt in der Lage mich weiter einzuarbeiten.
Dazu vielen Dank an alle, die hier wertvolle Tipps zur Problemlösung gegeben haben.
Viele Grüße
Rolf