Originally posted by: <email address deleted>
Hallo liebe FHEM-Gemeinde,
nach nun über 2 1/2 Jahren FHEM habe ich nun ein Problem, welches sich
mir adhoc nicht erschließt.
Im Sommer habe ich mein FHEM-Projekt von einem CH3SNAS (Debian Etch)
auf einen fullsize Rechner mit Debian Squeeze umgezogen. Installiert
hatte ich das fhem-5.0a.deb. Bis letztens die Temperaturen draußen
unter 0 Grad gefallen sind lief alles OK, dann aber hat der Bug bei
CUL_WS zugeschlagen
- - - - -
2011.10.17 07:48:56 1: Error: S300TH CUL_WS Cannot decode KB1049076
(sanitycheck). Malformed
- - - - -
und ich dachte mir, wird vermutlich Zeit für ein Update auf eine
aktuellere Version von fhem. Gemacht getan, das Paket fhem-5.1.deb
installiert und von da an ein paar Probleme.
1. Permission denied
- - - - - -
2011.10.18 00:43:55 3: CUL opening MyCUL device /dev/ttyACM0
2011.10.18 00:43:55 3: Can't open /dev/ttyACM0: Permission denied
- - - - - -
War vor dem Update nie ein Thema. Selbst ein hinzufügen des Users fhem
zur group dialout half nicht. Nur ein hartes Rechteverbiegen auf dem
Device ermöglicht fhem nun auf das CUL zu zugreifen.
- - - - - -
me@dd:~$ ls -l /dev/ttyACM0
crw-rw-rwx 1 root dialout 166, 0 Oct 18 11:20 /dev/ttyACM0
me@dd:~$ id fhem
uid=999(fhem) gid=999(fhem) groups=999(fhem),20(dialout)
- - - - - -
Ärgerlich, da nach einem Reboot (z.B. Stromausfall) die Rechte wieder
auf 0660 zurück gesetzt werden.
2. Kein Datenempfang
Nach dem Starten einige Minuten beobachtet was passiert - leider
nichts. Es werden vom CUL > FHEM keine Daten empfangen. Doppel-Check
der Konfiguration und restart brachten leider keine Daten zu Tage.
Ok, mal verbosity-Level hochsetzen auf 5 und siehe da, es kamen Daten.
Da bei 5 mehr Logs als Daten anfallen ist das natürlich keine Option
für den Betrieb, also wieder auf "3" runtergesetzt - Ergebnis: keine
Daten. Selbst wenn ich es wieder auf "5" setze kommt nichts bei FHEM
an.
Zusätzlich noch angemerkt, dass ich zwischenzeitlich ein Kernel-
Upgrade durchgeführt hatte aber eben jetzt erst einen Restart von fhem
- evtl. erst jetzt hier wirksam - allerdings eher unwahrscheinlich.
Hier einige Daten:
Debian Linux 2.6.32-5-amd64 x86_64
fhem-5.1
- - - - -
me@dd:~$ lsmod | grep ftdi_sio
ftdi_sio 33928 0
usbserial 27676 1 ftdi_sio
usbcore 122674 6
ftdi_sio,usbserial,cdc_acm,ohci_hcd,ehci_hcd
- - - - -
Auszüge aus StartUp-Log
- - - - -
2011.10.18 11:20:20 5: Cmd: >attr global logfile /var/log/fhem/fhem-%Y-
%m.log<
2011.10.18 11:20:20 5: Cmd: >attr global modpath /usr/share/fhem<
2011.10.18 11:20:20 5: Loading /usr/share/fhem/FHEM/99_SUNRISE_EL.pm
2011.10.18 11:20:20 5: Loading /usr/share/fhem/FHEM/99_Utils.pm
2011.10.18 11:20:20 5: Loading /usr/share/fhem/FHEM/99_XmlList.pm
2011.10.18 11:20:20 5: Loading /usr/share/fhem/FHEM/99_updatefhem.pm
2011.10.18 11:20:20 5: Cmd: >attr global port 7072<
2011.10.18 11:20:20 5: Cmd: >attr global statefile /var/log/fhem/
fhem.save<
2011.10.18 11:20:20 5: Cmd: >attr global verbose 5<
2011.10.18 11:20:20 5: Cmd: >define MyCUL CUL /dev/ttyACM0 0000<
2011.10.18 11:20:20 5: Loading /usr/share/fhem/FHEM/00_CUL.pm
2011.10.18 11:20:20 3: CUL opening MyCUL device /dev/ttyACM0
2011.10.18 11:20:20 3: CUL device opened
2011.10.18 11:20:20 5: CUL/RAW (ReadAnswer): V 1.24 CUL868
2011.10.18 11:20:20 5: CUL/RAW (ReadAnswer): 0000
2011.10.18 11:20:20 5: GOT CUL fhtid: 0000
2011.10.18 11:20:20 0: Server started (version 5.1 from 2011-07-08
($Id: fhem.pl,v 1.145 2011-07-07 08:46:28 rudolfkoenig Exp $), pid
2612)
- - - - -
Außer, dass die Firmware des CUL mittlerweile etwas alt ist fällt mir
nun nichts mehr ein. Irgendwelche Ideen?
Grüße,
Matze
PS: Danke an Alle, die an der SW/HW arbeiten!
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
> 2011.10.18 00:43:55 3: Can't open /dev/ttyACM0: Permission denied
Wenn fhem als root gestartet ist, dann versucht es (neuerdings) zu Benutzer
fhem und in die Gruppe dialout zu wechseln, und hofft, dass mit diesen Rechten
die /dev/XXX Eintraege geoffnet werden koennen. Wenn das nicht geht, dann liegt
es entweder daran, dass meine Theorie falsch ist (und debian/ubuntu serielle
Geraete der dialout Gruppe nicht zugaenglich macht), oder irgendetwas ging in
dieser Installation schief.
Wie schauen denn die Rechte von /dev/ttyACM0 nach reboot aus? Kann sein, dass
ein alter udev Eintrag ttyACM0 modifiziert?
> Ok, mal verbosity-Level hochsetzen auf 5 und siehe da, es kamen Daten.
Das ist fuer mich unglaublich. Was passiert in einem parallel laufenden
telnet mit "inform timer" und normalen loglevel? Klappt ein "get CUL version" ?
Hilft evtl. ein @38400 beim definieren von MyCUL?
> Außer, dass die Firmware des CUL mittlerweile etwas alt ist fällt mir
> nun nichts mehr ein. Irgendwelche Ideen?
1.24 ist mit 2 Jahren wirklich alt, sollte aber funktionieren.
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
erst mal danke für die schnelle Antwort!
On Oct 18, 12:42 pm, Rudolf Koenig wrote:
> > 2011.10.18 00:43:55 3: Can't open /dev/ttyACM0: Permission denied
>
> Wenn fhem als root gestartet ist, dann versucht es (neuerdings) zu Benutzer
> fhem und in die Gruppe dialout zu wechseln, und hofft, dass mit diesen Rechten
> die /dev/XXX Eintraege geoffnet werden koennen. Wenn das nicht geht, dann liegt
> es entweder daran, dass meine Theorie falsch ist (und debian/ubuntu serielle
> Geraete der dialout Gruppe nicht zugaenglich macht), oder irgendetwas ging in
> dieser Installation schief.
Also kann keine udev-Regeln in dieser Richtung unter /etc/udev/
rules.d/ finden, nur ein CD-Rom und ein ethX Eintrag.
> Wie schauen denn die Rechte von /dev/ttyACM0 nach reboot aus? Kann sein, dass
> ein alter udev Eintrag ttyACM0 modifiziert?
Nach dem Reboot müssten die Rechte folgendermaßen aussehen:
crw-rw---- 1 root dialout 166, 0 Oct 18 14:22 /dev/ttyACM0
> > Ok, mal verbosity-Level hochsetzen auf 5 und siehe da, es kamen Daten.
>
> Das ist fuer mich unglaublich. Was passiert in einem parallel laufenden
> telnet mit "inform timer" und normalen loglevel? Klappt ein "get CUL version" ?
> Hilft evtl. ein @38400 beim definieren von MyCUL?
@38400 eingetragen - leider keine Ergebnis.
ein "inform timer" ergibt nichts, sollte dann vermutlich eine Ausgabe
auf der telnet-Console provozieren, oder? Im Log tut sich auch nichts.
- - - - -
me@dd:~$ telnet localhost 7072
Trying ::1...
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
get CUL version
Please define CUL first
get MyCUL version
MyCUL version => V 1.24 CUL868
- - - - -
Das scheint zu passen, mein CUL heisst halt MyCUL.
weitere Telnet-Informationen:
- - - - -
list
Type list for detailed info.
_internal_:
global ()
CUL:
MyCUL (Initialized)
HMS:
Ruecklauf (T: 25.3 Bat: empty)
CUL_WS:
Aussen (T: 8.2 H: 82.8)
Bad (???)
Hobby (T: 22.2 H: 52.4)
Keller (???)
Wohnzimmer (???)
CUL_EM:
Heizung (CNT: 134 CUM: 44.353 5MIN: 0.000 TOP: 0.000)
notify:
AussenDB (active)
BadDB (active)
HeizungDB (active)
HobbyDB (active)
KellerDB (active)
RuecklaufDB (active)
WohnzimmerDB (active)
list global
Internals:
DEF
NAME global
NR 1
STATE
TYPE _internal_
currentlogfile /var/log/fhem/fhem-2011-10.log
logfile /var/log/fhem/fhem-%Y-%m.log
Attributes:
configfile /etc/fhem.cfg
logfile /var/log/fhem/fhem-%Y-%m.log
modpath /usr/share/fhem
port 7072
statefile /var/log/fhem/fhem.save
verbose 3
version 5.1 from 2011-07-08 ($Id: fhem.pl,v 1.145 2011-07-07
08:46:28 rudolfkoenig Exp $)
list MyCUL
Internals:
Clients :FS20:FHT:FHT8V:KS300:USF1000:BS:HMS: :CUL_EM:CUL_WS:CUL_FHTTK:CUL_RFR:CUL_HOERMANN: :ESA2000:CUL_IR:
DEF /dev/ttyACM0@38400 0000
DeviceName /dev/ttyACM0@38400
FD 6
FHTID 0000
NAME MyCUL
NR 2
PARTIAL
STATE Initialized
TYPE CUL
VERSION V 1.24 CUL868
initString X21
Matchlist:
1:USF1000 ^81..(04|0c)..0101a001a5ceaa00....
2:BS ^81..(04|0c)..0101a001a5cf
3:FS20 ^81..(04|0c)..0101a001
4:FHT ^81..(04|09|0d)..(0909a001|83098301|c409c401)..
5:KS300 ^810d04..4027a001
6:CUL_WS ^K.....
7:CUL_EM ^E0.................$
8:HMS ^810e04....(1|5|9).a001
9:CUL_FHTTK ^T........
A:CUL_RFR ^[0-9A-F]{4}U.
B:CUL_HOERMANN ^R..........
C:ESA2000 ^S................................$
D:CUL_IR ^I............
Readings:
2011-10-18 14:15:23 version V 1.24 CUL868
Attributes:
- - - - -
> > Au er, dass die Firmware des CUL mittlerweile etwas alt ist f llt mir
> > nun nichts mehr ein. Irgendwelche Ideen?
>
> 1.24 ist mit 2 Jahren wirklich alt, sollte aber funktionieren.
hatte es eben auch bis zum Update seit fast einem halben Jahr auf dem
neuen Blech und mit der 5.0a.
Ein Empfangsproblem kann ich weitestgehend ausschließen, da der CUL_EM
ca. 20cm vom CUL entfernt ist und der HMS nur durch eine Wand stets
zuverlässig überträgt - wenn auch die Batterie aktuell zu neige geht.
Grüße,
Matze
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
> Nach dem Reboot müssten die Rechte folgendermaßen aussehen:
> crw-rw---- 1 root dialout 166, 0 Oct 18 14:22 /dev/ttyACM0
Muessten == Sind? Damit wuerde aber ein Benutzer mit Gruppe dialout doch kein
permission deniad bekommen. Kannst Du bitte im telnet
{ `id -a` }
eingeben?
> ein "inform timer" ergibt nichts, sollte dann vermutlich eine Ausgabe
> auf der telnet-Console provozieren, oder? Im Log tut sich auch nichts.
Das loglevel sollte definitiv nichts an dem Events aendern. Kannst Du es auch
mit der CVS Version von fhem versuchen?
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
On Oct 18, 3:22 pm, Rudolf Koenig wrote:
> > Nach dem Reboot m ssten die Rechte folgenderma en aussehen:
> > crw-rw---- 1 root dialout 166, 0 Oct 18 14:22 /dev/ttyACM0
>
> Muessten == Sind? Damit wuerde aber ein Benutzer mit Gruppe dialout doch kein
> permission deniad bekommen. Kannst Du bitte im telnet
> { `id -a` }
> eingeben?
hatte jetzt keinen erneuten Reboot gemacht gehabt, bin mir ziemlich
sicher, dass die Rechte wie oben stehend waren bevor ich ein chmod
0667 auf ttyACM0 gemacht hatte. Aber ja, nach einem Reboot oder
erneuter Initialisierung des CUL sind die Rechte wieder zurückgesetzt,
daher keine dauerhafte Option per chmod den Zugriff zu ermöglichen.
- - - - - -
me@dd:~$ id -a fhem
uid=999(fhem) gid=999(fhem) groups=999(fhem),20(dialout)
- - - - - -
> > ein "inform timer" ergibt nichts, sollte dann vermutlich eine Ausgabe
> > auf der telnet-Console provozieren, oder? Im Log tut sich auch nichts.
>
> Das loglevel sollte definitiv nichts an dem Events aendern. Kannst Du es auch
> mit der CVS Version von fhem versuchen?
Reicht der Austausch des fhem.pl-Skripts oder muss ich CVS-Version
voll installieren?
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Am 18.10.2011 um 15:57 schrieb Matze:
> hatte jetzt keinen erneuten Reboot gemacht gehabt, bin mir ziemlich
> sicher, dass die Rechte wie oben stehend waren bevor ich ein chmod
> 0667 auf ttyACM0 gemacht hatte. Aber ja, nach einem Reboot oder
> erneuter Initialisierung des CUL sind die Rechte wieder zurückgesetzt,
> daher keine dauerhafte Option per chmod den Zugriff zu ermöglichen.
Das hier hattest Du schon probiert?
http://groups.google.com/group/fhem-users/browse_thread/thread/3dcc1524dcd8c6b5/a0a0b45cd520eb7a?lnk=gst&q=udev+rules#a0a0b45cd520eb7a
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
On Oct 18, 4:08 pm, Dirk Tostmann wrote:
> Am 18.10.2011 um 15:57 schrieb Matze:
>
> > hatte jetzt keinen erneuten Reboot gemacht gehabt, bin mir ziemlich
> > sicher, dass die Rechte wie oben stehend waren bevor ich ein chmod
> > 0667 auf ttyACM0 gemacht hatte. Aber ja, nach einem Reboot oder
> > erneuter Initialisierung des CUL sind die Rechte wieder zurückgesetzt,
> > daher keine dauerhafte Option per chmod den Zugriff zu ermöglichen.
>
> Das hier hattest Du schon probiert?
>
> http://groups.google.com/group/fhem-users/browse_thread/thread/3dcc15...
Diesen hatte ich in der Tat schon gelesen gehabt aber niemals in
Verbindung damit gebracht, da fhem ja das CUL-Device öffnen konnte
nach dem ich die Rechte getweakt hatte.
Verstehen tu ich es allerdings nicht warum es nun mit dem Symlink
funktioniert und vorher nicht - strange.
Vielen Dank für die schnelle Hilfe!
Matze
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Am 18.10.2011 um 17:31 schrieb Matze:
> Verstehen tu ich es allerdings nicht warum es nun mit dem Symlink
> funktioniert und vorher nicht - strange.
Entscheidend ist: OWNER="fhem", GROUP="fhem", MODE="660"
... das mit dem SymLink ist in Deinem Fall ein Nebeneffekt, wirst Du erst bei mehreren CUL benötigen.
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com