Benötige einen Input was ich nicht gemacht / falsch gemacht habe:
Benutze CUL Version V 1.52 an einer Fritz!Box 7270
Clients :CUL_MAX:HMS:CUL_IR
Wenn ich die minimale Konfiguration gemäss fhemwiki MAX eintrage und speichere ist die Rückmeldung:
"ERROR:
Unknown module CUL_MAX, choose one of ALL3076 ALL4000T ALL4027 BS CM11 CUL CUL_EM CUL_FHTTK CUL_HM CUL_HOERMANN CUL_IR CUL_RFR CUL_TX CUL_WS...."
Anbei Log-File
Bitte per update (//fhem.de/commandref.html#update) FHEM auf den neusten Stand bringen.
Danke für die Antwort.
Habe nach "update stable" gleiches Ergebnis erhalten.
Habe dann noch "update development" versucht. Dies schien mir einen unstabilen Zustand ergeben zu haben.
Habe dann ganzes FHEM gelöscht und anschliessend mittels Neuinstallation und neuerlichem "update stable" dasselbe Ergebnis erzielt.
Weiss nicht weiter...
Ich kenne mich mit update nicht aus, da ich direkt auf der SVN Version arbeite.
Vielleicht kann einer der anderen Foren-Nutzer sagen, wie er updated (auf stable oder development).
Das wäre dann auch ein guter Eintrag für die FAQ.
Könnte mir jemand bestätigen, dass CUL_MAX ein ganz normales Modul ist (wie z.B. 10_CUL_HM.pm) und auch im Unterverzeichnis FHEM abgelegt sein sollte (bei mir gibt es auf jeden Fall keine Datei, die in etwa einem CUL_MAX .pm entspricht, in diesem Verzeichnis).
Könnte ich nicht die Datei betreffend dem CUL_MAX Modul in dieses Verzeichnis kopieren?
Die Datei heisst 14_CUL_MAX.pm
Wer wagt gewinnt! (manchmal)
Habe 14_CUL_MAX.pm von SVN heruntergeladen. Darauf die Meldung "Cannot load module CUL_MAX" erhalten. Sicherheitshalber auch die Datei 10_MAX.pm dazu gefügt.
Meldung bleibt "Cannot load module CUL_MAX"
Log:
2013.02.12 10:15:59 2: Switched CUL0 rfmode to MAX
2013.02.12 10:15:59 5: Cmd: >define cm CUL_MAX 123456<
2013.02.12 10:15:59 5: Loading ./FHEM/14_CUL_MAX.pm
2013.02.12 10:16:00 1: reload: Error:Modul 14_CUL_MAX deactivated:
Can't locate MaxCommon.pm in @INC (@INC contains: /var/InternerSpeicher/JetFlash-TS1GJFV20-01/fhem/lib/perl /var/InternerSpeicher/JetFlash-TS1GJFV20-01/fhem/lib/perl/arch /home/rudi/fbperl/lib/perl/arch /home/rudi/fbperl/lib/perl . ./FHEM) at ./FHEM/14_CUL_MAX.pm line 8, <$fh> line 45.
BEGIN failed--compilation aborted at ./FHEM/14_CUL_MAX.pm line 8, <$fh> line 45.
2013.02.12 10:16:00 0: Can't locate MaxCommon.pm in @INC (@INC contains: /var/InternerSpeicher/JetFlash-TS1GJFV20-01/fhem/lib/perl /var/InternerSpeicher/JetFlash-TS1GJFV20-01/fhem/lib/perl/arch /home/rudi/fbperl/lib/perl/arch /home/rudi/fbperl/lib/perl . ./FHEM) at ./FHEM/14_CUL_MAX.pm line 8, <$fh> line 45.
BEGIN failed--compilation aborted at ./FHEM/14_CUL_MAX.pm line 8, <$fh> line 45.
Danke für den Hinweis.
Marcel
MaxCommon.pm fehlt wohl auch noch.
Wer lesen kann ist im Vorteil...
Auch noch die im Log als fehlend bezeichnete Datei MaxCommon.pm eingefügt.
Log:
2013.02.12 10:36:05 2: Switched CUL0 rfmode to MAX
2013.02.12 10:36:05 5: Cmd: >define cm CUL_MAX 123456<
2013.02.12 10:36:05 5: Loading ./FHEM/14_CUL_MAX.pm
2013.02.12 10:36:06 1: reload: Error:Modul 14_CUL_MAX deactivated:
Global symbol "$readingFnAttributes" requires explicit package name at ./FHEM/14_CUL_MAX.pm line 42, <$fh> line 45.
2013.02.12 10:36:06 0: Global symbol "$readingFnAttributes" requires explicit package name at ./FHEM/14_CUL_MAX.pm line 42, <$fh> line 45.
So, jetzt glaube ich, dass ich definitiv am Ende (meiner) Fahnenstange angelangt bin.
Die Max Module funktionieren eben nur mit aktullem FHEM. Also doch ein Update auf development machen?
> Vielleicht kann einer der anderen Foren-Nutzer sagen, wie er updated (auf stable oder development).
Es ist im Moment egal, was der Nutzer nutzt (stable, development). Zur Zeit ist ein Update ausschließlich "development". Dies ist eine Entscheidung von Rudi.
Angedacht war es, das mit einer neuen Release nur noch "wichtige" Update (Sicherheit, Funktion, etc. beeinträchtigt) über "stable" ausgeliefert werden. Im Gegensatz sollte über "development" auch die jeweils aktuellen Entwicklungsstände aktualisierbar sein. "update" ist von mir so "gebaut", dass es das unterstützt, sowie (theoretisch) weitere "Pakete". Standard ist immer "fhem", was wiederum bedeutet, das zur Zeit _alles_ aktualisiert wird. Gedacht war ursprünglich das "reine fhem" (konsolenbasiert) von der GUI (FHEMWEB) zu trennen, so daß der Nutzer selber entscheiden kann, was er aktualisieren will. Denkbar wäre auch "update contrib", welches dann z.B. nur das "contrib" Verzeichnis aktualisieren würde, wenn wir es denn einbauen würden. "update" kann noch einiges mehr, was ich aber hier jetzt nicht weiter ausführen möchte.
Zusammenfassung:
Ein "update" aktualisiert (zur Zeit) _immer_ die komplette FHEM Distribution (Ausnahme: contrib Verzeichnis) aus dem SVN (welches jeden Morgen in den "update-stream" kopiert wird) und ist somit (zur Zeit) _immer_ "development".
Ein mehrfaches Ausführen von "update" am selben Tag aktualisiert nach dem ersten Aufruf (nach 08:00) nichts mehr, es sei denn, Rudi hat manuell den Abgleich SVN -> "update-stream" aus wichtigem Grund angestoßen.
Gruß Martin
Danke für diesen Hinweis.
"update development" durchlaufen lassen.
Nun stirbt FHEM bei jedem Befehl, den ich via Webkonsole eingebe. Sei dies Logfile anzeigen oder edit > und muss via Telnet neu gestartet werden.
Vor dem letzten Lebenshauch gibt Telnet noch als Hinweis:
"Undefined subroutine &main::Dumper called at ./FHEM/14_CUL_MAX.pm line 354."
Zeile 354:
"Log 5, "CUL_MAX_BroadcastTime: payload $payload ". Dumper($modules{MAX}{defptr});"
Marcel
Danke für die ausführlichen Hinweise!
Den Fehler hab ich auch schon entdeckt.
Siehe Link (http://forum.fhem.de/index.php?topic=11040.msg63615#msg63615)
Entweder meinen Workaround anwenden oder bis morgen auf das nächste Update warten.
> Danke für diesen Hinweis.
aber:
> "update development" durchlaufen lassen.
ist nicht notwendig, da wie ich schrieb "update" _immer_ gleich "development".
also einfach nur ein "update" reicht und spart das tippen ;-)
Danke. Ich verstehe, dass kein Unterschied sein sollte.
Ich habe heute mehrfach FHEM neu installiert und anschliessend geupdatet. Sowohl mit update stable, update development, oder update development fhem.
Als Ergebnisse hatte ich:
- Schwarzer Hintergrund mit gerade stehendem Haus (statt schief mit Smily)
- Undefined subroutine &main::Dumper called at ./FHEM/14_CUL_MAX.pm line 354.
- Global symbol "$readingFnAttributes" requires explicit package name at ./FHEM/14_CUL_MAX.pm line 42, <$fh> line 45
- Global symbol "$readingFnAttributes" requires explicit package name at ./FHEM/14_CUL_MAX.pm line 42, <$fh> line 55
Als Novize schreibe ich dieses unterschiedliche Verhalten teilweise meinen Fehlern zu (so bin ich vermutlich für den schwarzen Hintergrund verantwortlich, da ich dem System nicht genügend Zeit zum Update gegeben habe - wie ich den Vorgang unterbrochen habe, kann ich mich im Nachhinein nicht mehr erinnern).
Auch wenn das als stur erscheinen mag. So lange ich nicht das gleiche Ergebnis reproduzieren kann, versuche ich möglichst überhaupt nichts zu verändern (auch wenn dies "unnötige" Arbeit verursacht). Bis jetzt habe ich die Erfahrung gemacht, dass dies schneller Resultate bringt, als an mehreren Schräubchen gleichzeitig zu drehen.
Ich bitte auf jeden Fall um Nachsicht.
Marcel
P.S. hoffe, dass mit dem Update vom 13. alles klappt.
Hallo,
> Danke. Ich verstehe, dass kein Unterschied sein sollte.
ich denke nicht, das Du es verstanden hast. Es besteht _kein_ Unterschied!
> Ich habe heute mehrfach FHEM neu installiert und anschliessend geupdatet.
> Sowohl mit update stable, update development, oder update development fhem.
siehe oben: einfach _nur_ "update". Alles andere ist zur Zeit sinnfrei und macht genau das Gleiche wie "update" ohne zusatz von stable, development, etc.
Um tatsächlich _alles_ nochmal neu herunter zu laden, kannst Du ein "update force" ausführen.
Ich beziehe mich hierbei nur auf den Aufruf von "update". Mit den anderen Punkten hat dieser Hinweis nichts zu tun.
Gruß Martin
Danke! Nach update force gibt es die geschilderten Probleme nicht mehr.
Marcel
> Danke! Nach update force gibt es die geschilderten Probleme nicht mehr.
Prima...
Gruß Martin