[FHZ] Fritzbox 7170: Undefined subroutine &main::LIRC_Initialize

[Dr. Boris Neubert]

Originally posted by: <email address deleted>

Hello,

I am absolutely new to FS20, FHEM and all of this.
Planning to make one room's heating remotely controllable via
Internet.

I bought a Fritz 7170 (as I was absolutely unable to get onto my
3070WLAN via telnet).
The Firmware is 4.57, not 4.49, but according to uname and ls the
kernel and uclib
versions are exactly the same.
I installed as described, kernel modules are loaded successfully.
Start of fhem.pl fails with the following message in the log:
 2009.01.12 01:17:43 1: Undefined subroutine &main::LIRC_Initialize
called at fhem.pl line 1264, <$fh> line 10.

Now where does this infrared remote control thing come from? Or is it
something else?
I am quite clueless when it comes to Perl, the function in this line
1264 somehow tries to call
initialization functions of modules. Which modules? Any idea what is
going wrong and how I
can correct this?

Asking questions here I have another one: Will the web server at 8083
be remotely accessible (from Internet side) or at least is it possible
to make it accessible? (If not, I should not have bought all this
hardware.. FHZ1300, FHT80b)
If accessible from Internet, I sure would need some login and SSL. Any
chance for this on the Fritzbox?

Thanks!
Florian

PS: group language is said to be English, but lot of German posts -
would be my native lang too, if most of you prefer it I would too..


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "FHZ1000 users on Linux" group.
To post to this group, send email to FHZ1000-users-on-unix@googlegroups.com
To unsubscribe from this group, send email to FHZ1000-users-on-unix+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/FHZ1000-users-on-unix?hl=en
-~----------~----~----~----~------~----~------~--~-

[rudolfkoenig]

                                                   

> Start of fhem.pl fails with the following message in the log:
>  2009.01.12 01:17:43 1: Undefined subroutine &main::LIRC_Initialize
> called at fhem.pl line 1264, <$fh> line 10.

This is a typical for the FAT32 problem (the module files in the FHEM
subdirectory are not created exactly with the same case as expected),
which should be solved in the current version of fhem. Another feature
of the current fhem is to load only the needed modules, explicitly
developed for such small systems like the Fritz!Box. You probably can
solve your problems by either upgrading to a current fhem version or
correct the casing of the needed modules (or rename the Initialize
function so that it matches the file casing). Remove all other modules
from the FHEM directory for the old fhem.

> Asking questions here I have another one: Will the web server at 8083
> be remotely accessible (from Internet side) or at least is it possible
> to make it accessible? (If not, I should not have bought all this
> hardware.. FHZ1300, FHT80b)

This is not directly a fhem but a Fritz!Box issue. You must persuade
it to route an external port to a local one. I've not yet done this,
but current Firmware versions seem to have an option "Fernwartung",
which probably could be used for this purpose.

Greetings,
  Rudi
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "FHZ1000 users on Linux" group.
To post to this group, send email to FHZ1000-users-on-unix@googlegroups.com
To unsubscribe from this group, send email to FHZ1000-users-on-unix+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/FHZ1000-users-on-unix?hl=en
-~----------~----~----~----~------~----~------~--~-

[rudolfkoenig]

Originally posted by: <email address deleted>

Thanks for the quick answer. But it seems that all of this will take
some
more time than I first thought it would..

> >  2009.01.12 01:17:43 1: Undefined subroutine &main::LIRC_Initialize
> > called at fhem.pl line 1264, <$fh> line 10.
> This is a typical for the FAT32 problem (the module files in the FHEM
> subdirectory are not created exactly with the same case as expected)

I used tar directly on the FB to unpack your .tar distribution (0.4).
(Btw, did not find a notice what version is in there, according to
file date
probably 4.2? As the file case fix you mentioned seems to be in 4.3).
The modules filenames seem to have the right case. As you see in the
error message from the log, LIRC_Initialize is searched, and that is
exactly how it is written in the 00_LIRC.pem.

I tried to unpack on Windows, after that the error message
was about lirc_Initialize, what indeed would be wrong (and the file
was named 00_lirc.pem then).

So I do not really know why the function is not found. The subdir
FHEM however is shown in lowercase (fhem) in both cases. Have
something in mind like filenames with max 8 characters will
never have case in FAT? But the module files are somehow found
after all, as this seems to be the source for the different error
messages.

Other than that, I do not really know what modules I need or not,
just wanted to get it basically started for the moment.

> which should be solved in the current version of fhem. Another feature
> of the current fhem is to load only the needed modules, explicitly
> developed for such small systems like the Fritz!Box. You probably can
> solve your problems by either upgrading to a current fhem version

I also do not know how to correctly upgrade fhem in the FB
distribution.
What I tried was: replacing fhem.pl and subdir FHEM with that from
generic 4.5 tar. Now with this, the above error disappears. But now
I get errors like I should define HTTP, WEB, FHZ. All of this is in
the
(old) fhem.cfg. It says "server started", but there is nothing at port
8083.

> but current Firmware versions seem to have an option "Fernwartung",
> which probably could be used for this purpose.

This only gives access to the FB web administration itself. And port
forwarding to the address of the FB itself is prohibited. But with
alternative Firmware like Freetz this seems to be achievable (what
then hopefully will still allow fhem).

As I said, all of this will take quite some more time..

I really wonder why they do not build a little webserver and ethernet
interface directly into that FHZ-1000 (non-PC) central control unit
itself. Nowadays, where fridges and coffee machines are Internet
accessible..
Instead they provide a Windows proprietary software requiring a
desktop to run all the time - ridiculous

So Thanks for providing FHEM, but at the moment it seems quite
a lot to learn until I can use it..

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "FHZ1000 users on Linux" group.
To post to this group, send email to FHZ1000-users-on-unix@googlegroups.com
To unsubscribe from this group, send email to FHZ1000-users-on-unix+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/FHZ1000-users-on-unix?hl=en
-~----------~----~----~----~------~----~------~--~-

[Guest]

Originally posted by: <email address deleted>

Little update..

After copying the files from (4.5) webfrontend/pgm2 to the FHEM
subdir too and specifying WEB instead of HTTP in the config,
the web frontend is running. The FHZ1300PC seems to be
recognized (just bought my first USB hub ever, never needed
one before..), can be found as FHZ in the frontend.
Web root for commandref etc also seems to be the FHEM subdir.

Will try to connect to a FHT80b at the weekend..


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "FHZ1000 users on Linux" group.
To post to this group, send email to FHZ1000-users-on-unix@googlegroups.com
To unsubscribe from this group, send email to FHZ1000-users-on-unix+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/FHZ1000-users-on-unix?hl=en
-~----------~----~----~----~------~----~------~--~-

[Dr. Boris Neubert]

Originally posted by: <email address deleted>

Also ich mach hier jetzt auch mal auf Deutsch weiter..

Vorab nochmal zum Topic: warum die dort genannte Fehlermeldung
mit der Original-Version des FB-tar bei mir auftauchte, hat sich nie
geklärt. Habe auf die aktuelle Version umgerüstet, hoffentlich
korrekt.

Nachdem also zuletzt alles scheinbar funktioniert hat, ist es damit
vorbei, seit ich versucht habe es konkret zu benutzen. Einziger
Unterschied: in der Nähe des FHZ lag nun ein FHT. Und zwar
stürzt nun die FB jedesmal innerhalb von ein paar Sekunden ab,
sobald ich FHEM (bei angestecktem FHZ) starte.

Den USB-Hub habe ich testweise auch mit Netzteil versorgt -
das macht keinen Unterschied! Auch vom Speicher-Problem
habe ich gelesen. Starte ich FHEM ohne FHZ, bleiben gut
2MB RAM noch frei. Reicht das nicht, wenn die FHZ dann
tatsächlich Daten schickt? Sollte nicht eigentlich dafür das
swapfile einspringen? Auch killen von ein paar Prozessen
(telefon, brauch ich eh nicht) vorher hat nicht geholfen.
Jedesmal bevor ich irgendwas tun kann - Schwups, FB bootet neu!

Was kann ich noch versuchen?

Alle weiteren Experimente leider erst übernächstes WoE -
an dem Ort, den ich eigentlich diesmal schon per INet vorab
aufheizen wollte.. (Brrr!)

Florian

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "FHZ1000 users on Linux" group.
To post to this group, send email to FHZ1000-users-on-unix@googlegroups.com
To unsubscribe from this group, send email to FHZ1000-users-on-unix+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/FHZ1000-users-on-unix?hl=en
-~----------~----~----~----~------~----~------~--~-

[Dr. Boris Neubert]

                                                   

> Nachdem also zuletzt alles scheinbar funktioniert hat, ist es damit
> vorbei, seit ich versucht habe es konkret zu benutzen. Einziger
> Unterschied: in der Nähe des FHZ lag nun ein FHT. Und zwar
> stürzt nun die FB jedesmal innerhalb von ein paar Sekunden ab,
> sobald ich FHEM (bei angestecktem FHZ) starte.

Bei mir war dieser Absturz nur mit einem gesteckten EM1010PC zu
beobachten, der FHZ1000PC funktionierte fein.

> Sollte nicht eigentlich dafür das swapfile einspringen?
Ich konnte es auch nicht beobachten, dass irgendetwas rausgeswapped
wurde.

> Was kann ich noch versuchen?

"cat /dev/elv0", um zu pruefen, ob es ein fhem Problem ist.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "FHZ1000 users on Linux" group.
To post to this group, send email to FHZ1000-users-on-unix@googlegroups.com
To unsubscribe from this group, send email to FHZ1000-users-on-unix+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/FHZ1000-users-on-unix?hl=en
-~----------~----~----~----~------~----~------~--~-

[Guest]

Originally posted by: <email address deleted>

Gerade anderen USB-Hub und anderen USB-Stick getestet,
gleiches Problem.

Ich habe keinen FHZ1000PC, sondern 1300PC (nix WLAN) - stand
aber ja gleichermassen da "getestet".

Meintest Du bei Dir wird nicht geswapped, weil es nicht notwendig
ist, oder dass der swap-Mechanismus gar nicht funktioniert?

Ich kann jetzt leider bestätigen, dass auch ganz ohne Start von
fhem der Reboot auftritt, sobald ich das device anspreche, also
eben per cat. Meistens praktisch sofort, manchmal
dauert es noch ein bisschen und man sieht vor dem Freeze
noch ein Zeichen auftauchen.

Woran kann das nun liegen? Passen die Module nicht? (sie
werden anstandslos geladen und von lsmod angezeigt).
Warum hatte ich das Problem bei meinen ersten Versuchen
damals noch nicht? Mysteriös..

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "FHZ1000 users on Linux" group.
To post to this group, send email to FHZ1000-users-on-unix@googlegroups.com
To unsubscribe from this group, send email to FHZ1000-users-on-unix+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/FHZ1000-users-on-unix?hl=en
-~----------~----~----~----~------~----~------~--~-

[Dr. Boris Neubert]

                                                   

> Ich habe keinen FHZ1000PC, sondern 1300PC (nix WLAN) - stand
> aber ja gleichermassen da "getestet".

Stimmt, ich habe beide geprueft.

> Meintest Du bei Dir wird nicht geswapped, weil es nicht notwendig
> ist, oder dass der swap-Mechanismus gar nicht funktioniert?

Ich glaub letzteres, da ich versucht habe swappen zu provozieren.
Wahrscheinlich ist der kernel ganz ohne swap uebersetzt, damit spart
man ueberfluessige Bytes. Und wenn das stimmt, dann koennte man die
32MB Swap-Datei auch sparen....

> Woran kann das nun liegen? Passen die Module nicht?

Das ist durchaus moeglich, insb. wenn es mit einem anderen FW Version
gemacht wird als das was ich als Grundlage genommen habe. Evtl sollte
man das Modul neu uebersetzen. Oder den syslog umleiten, vielleicht
sieht man noch was... Ich habe im Netz eine weile gesucht, aber die
meisten wollen nur USB-Sticks oder Festplatten anschliessen, und das
scheint kein reboot zu provozieren.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "FHZ1000 users on Linux" group.
To post to this group, send email to FHZ1000-users-on-unix@googlegroups.com
To unsubscribe from this group, send email to FHZ1000-users-on-unix+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/FHZ1000-users-on-unix?hl=en
-~----------~----~----~----~------~----~------~--~-

[Guest]

Originally posted by: <email address deleted>

> Das ist durchaus moeglich, insb. wenn es mit einem anderen FW Version
> gemacht wird als das was ich als Grundlage genommen habe.

Tja, wie gesagt, ist die identische Kernel-Version, zumindest vom
Namen her. Sonst würden ja die Module im rc-Skript gar nicht gefunden.

Aber evtl. probiere ich mal ein Downgrade (ich hoffe sowas ist
erlaubt),
die .49 habe ich nach langem Suchen gefunden. Dabei wäre jetzt
schon die .67 aktuell.

> Oder den syslog umleiten, vielleicht sieht man noch was...

Und wie geht das? /var/log ist leer, unter /etc findet sich auch
nichts
Richtung syslog? Und würde er es überhaupt noch auf den flash
schreiben können, bevor er stirbt?

> Ich habe im Netz eine weile gesucht, aber die meisten wollen nur
> USB-Sticks oder Festplatten anschliessen, und das scheint kein reboot zu provozieren.

Du meinst an die FB? Das geht ja schon im Auslieferungszustand, klar,
Dateiserver ist eins der beworbenen Features.

> Evtl sollte man das Modul neu uebersetzen.

Abgesehen davon dass mich das möglicherweise leicht überfordert:
wenn dann vermutlich mit einer anderen Compiler-Version als der
von Dir verlinkten? (welche?) Oder wie soll sich sonst durch
Neu-Kompilieren was ändern? Oder gibt es von AVM zu jeder FW-
Version die Kernel-Quellen?
Und dann fehlt noch die Info, welche Änderungen Du an dem Modul
machen musstest (für die ELV-Hardware: The ftdi_sio module had to
be modified, as 2.16.13 does not contain the USB ID's of the ELV
devices.).

Wie ist das eigentlich mit diesem Freetz - enthält das die notwendigen
Module evtl. auch? Wär doch mal nett, fhem als eins dieser Freetz-
Module

Danke für die Unterstützung!

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "FHZ1000 users on Linux" group.
To post to this group, send email to FHZ1000-users-on-unix@googlegroups.com
To unsubscribe from this group, send email to FHZ1000-users-on-unix+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/FHZ1000-users-on-unix?hl=en
-~----------~----~----~----~------~----~------~--~-

[Guest]

Originally posted by: <email address deleted>

Tada, bekomme es nun prompt wieder nicht mehr reproduziert,
nachdem ich die Kiste mitgenommen habe um weiterzubasteln.
Hier ist nun wieder kein FHT in der Nähe - schon montiert am
Bestimmungsort. Ohne den Fehler zu haben brauche ich auch
nicht rumzuprobieren.

Kann das sein, dass das Problem wirklich erst auftaucht,
sobald der/die/das FHZ wirklich per Funk was empfängt - was
dann also häufig "sofort" passiert, beim ersten cat auf das
device? (oder hängt schon was in irgendeiner Queue?)

Ich fürchte bis ich das am Laufen habe ist die Heiz-Saison
vorbei.. wieder vor Ort übernächstes WoE.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "FHZ1000 users on Linux" group.
To post to this group, send email to FHZ1000-users-on-unix@googlegroups.com
To unsubscribe from this group, send email to FHZ1000-users-on-unix+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/FHZ1000-users-on-unix?hl=en
-~----------~----~----~----~------~----~------~--~-

[Guest]

Originally posted by: <email address deleted>

Wieder vor Ort war der Fehler sofort wieder da. Mit der älteren
FW .49 getestet: gleiches Problem.
Die aktuelle .67 hat übrigens immer noch gleichen Kernel,
aber uclib ist eins hochgezählt, perl läuft nicht mehr.

Irgendwer hier der wirklich eine FB mit der FHZ1300PC in
Betrieb hat, mit den Modulen aus dem .tar? Wenn ja, kanns ja
nur noch eine HW-Änderung (oder Defekt) in meiner FB sein,
ist nur eher unwahrscheinlich.

Ich gebe für den Moment auf, keine Musse mehr. Vielleicht
irgendwann ein Versuch mit der NSLU.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "FHZ1000 users on Linux" group.
To post to this group, send email to FHZ1000-users-on-unix@googlegroups.com
To unsubscribe from this group, send email to FHZ1000-users-on-unix+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/FHZ1000-users-on-unix?hl=en
-~----------~----~----~----~------~----~------~--~-