win und fhem - probieren wirs mal ... machbarkeit, tippsammlung

[the ratman]

du, ich find den weg echt genial, hab aber bedenken. eingeschränkt ist das ding ja definitiv.
z.b. könntest du out of the box keine grafische oberfläche lauffähig kriegen. gibt zwar ne "hack-anleitung" dafür im netz, aber da bin ich geistig weggebrochen *g*.
zumindest denk ich mir, dass das nicht die einzige einschränkung sein könnte. drum auch gleich meine frage ...

[Alibaba]

Zeile 1656 ist die letzte Zeile von CommandSave. Entweder bezieht sich dein Patch auf eine veraltete FHEM Version, oder es ist Zeile 1686 gemeint.

Oh, Schreibfehler.
Es war natürlich Zeile 1686.
Ich setze wenn möglich immer den neusten Stand von Fhem ein.

[Alibaba]

Kannst du bitte noch testen, ob FHEM als Windows-Service zu aktivieren noch geht?

Der Aufruf geht unter perl64.
Einziger Unterschied zu perl32 in der Registrierungsdatenbank von Windows => der Eintrag  WOW64 (Reg_DWORD) = 1 fehlt.
Dies ist für 64-Bit Programme korrekt

[rudolfkoenig]

Schade, d.h. Win32::Daemon::CreateService ist nicht ganz 64-Bit faehig.
Kannst du fuer FHEM/WinService.pm einen Patch schreiben?

[herrmannj]

Bringt der Linux Unterbau auf win dann auch solche Sachen wie einheitliche konstanten bei fcnt (zB nonblocking) oder ein select auf nicht Network sockets mit?

[Alibaba]

Schade, d.h. Win32::Daemon::CreateService ist nicht ganz 64-Bit faehig.
Kannst du fuer FHEM/WinService.pm einen Patch schreiben?

meiner Meinung nach ist der Win32::Daemon 64-Bit fähig. Wie komst du darauf?

Bei mir funktioniert der Befehl C:\Perl64_5.24.2.2403\bin\perl.exe F:/fhem/fhem.pl F:/fhem/fhem.cfg -i korrekt. Windows-Dienst wird angelegt und funktioniert danach auch korrekt.
Ich führe danach zwei Änderungen aus Sicherheitgründen durch.
1. Dienst wird mit einem eingeschränkten User FHEMService ausgeführt
2. Der User FHEMService bekommt das Recht den Service FHEM zu starten und stoppen => sonst funktioniert mit einem User ohne Adminrechten ein shutdown restart nicht

[rudolfkoenig]

Ich habe offensichtlich deinen Beitrag nicht aufmerksam gelesen, und nur das "fehlt" gesehen. Sorry fuer die Verwirrung.

[fl_Indigo]

du, ich find den weg echt genial, hab aber bedenken. eingeschränkt ist das ding ja definitiv.
z.b. könntest du out of the box keine grafische oberfläche lauffähig kriegen. gibt zwar ne "hack-anleitung" dafür im netz, aber da bin ich geistig weggebrochen *g*.
zumindest denk ich mir, dass das nicht die einzige einschränkung sein könnte. drum auch gleich meine frage ...

grafische oberfläche brauch ich unter windows eh keine zusätzliche

habs nur schnell in der arbeit probiert, deshalb hab ich auch keine aussage zum produktiveinsatz. am homeserver daheim läuft windows 7, daher auch auf die schnelle kein test möglich...
ich glaube aber das es immer noch eine bessere möglichkeit darstellt als die krücke direkt unter windows laufen zu lassen...

[Wolfgang Hochweller]

Also, so weit ich es benutze, geht alles - einschliesslich Win32::SerialPort.
In Verwendung : Windows 10 mit OpenSSl, FHEM als Service ( mit ein paar Ungereimheiten, funktioniert aber ), Strawberry Perl, RFXTRX, Z-Wave, Hyperion, Internet Radio, Verbindung zur Verisure Alarmanlage ( Python ) , HTTPS, RemoteServer, IP-Kameras ( sofern sie was besseres als RTSP koennen )
Einzige Unklarheit ist eine Fehlermeldung beim Einbinden des FHEM-Logfiles, aber er funktioniert.

Kleiner Nachtrag : LGTV_WebOS funktioniert, fuellt aber das Logfile mit reichlich Fehlermeldungen ( sowohl Windows als auch Linux )
, musste ich daher abschalten.

[Alibaba]

Also, so weit ich es benutze, geht alles - einschliesslich Win32::SerialPort.
In Verwendung : Windows 10 mit OpenSSl, FHEM als Service ( mit ein paar Ungereimheiten, funktioniert aber ), Strawberry Perl, RFXTRX, Z-Wave, Hyperion,

Geht bei dir auch fork oder hast du nofork gesetzt? (Wobei bei mir unter Acriveperl trotz nofork=1 Fehlermeldungen und sporadische Abstürze aufgetaucht sind)
In der Zwischenzeit teste ich eine von mir geänderte blocking.pm und fhem.pl. Mit dieser gibt es jetzt keinerlei Fehlermeldungen und es läuft sehr stabil!
Nur beim shutdown treten noch vereinzelt Fehlermeldungen auf, aber ohne jegliche Auswirkung.

Welche Ungereimtheiten hast du bei FHEM als Service? Bei mir (Activeperl 32-bit oder 64-bit und Windows 2012R2) funktioniert dies einwandfrei.

[Wolfgang Hochweller]

fork bzw. nofork muesste ich untersuchen, habe ich mich nicht drum gekuemmert ..

Service :
FHEM verabschiedet sich gelegentlich, ohne dass ich sehen könnte, warum.
Danach muss man den Service wieder von Hand starten, automatisch geht dann nichts mehr.
Aehnliches passiert ab und an, wenn man den Rechner neu startet; manchmal startet der FHEM-Service, manchmal aber auch nicht.
Allerdings nicht weiter schlimm, ein Restart des Rechners passiert nie unbemerkt.
shutdown restart geht,
update all geht auch, aber erfordert einen manuellen Restart des Windows-Service( besser gesagt, man muss den Perl-Interpreter stoppen und kann dann den Service wieder starten).

[czcbe]

Hallo zusammen

Habt ihr inzwischen was Neues rausgefunden? Also ich habe meinen kürzlich gebauten nanoCul in Windows/Strawberry Perl nicht zum Laufen gebracht, mal ging es kurz, das 2. oder 3. mal fand er den COM-Port nicht mehr etc. Da musste ich leider nach etlichen Versuchen aufgeben. In Linux läuft er stabil. Sonst läuft es in Windows aber nicht schlecht.
Verstehe ich das richtig, dass mit nofork=1 in den GLOBAL-Einstellg. evtl. nicht gleichzeitig auf script-Files (z. Bsp. aus Presence) zugegriffen werden kann?

[Wolfgang Hochweller]

Mein FHEM ( windows 10, letzte Version ) stuerzt ab und an mit der folgenden Fehlermeldung ab :

Code: [Auswählen]


ERROR: Select error -1 (128), error count= 0
Select error -1 (128)


Worauf kann das hindeuten ?

Ansonsten laeuft es prima.

Von wegen COM-Port :

Ist der Port da, wird nur nicht gefunden ?

Ist ein anderer, neuer COM-Port da ?
In vielen Faellen erhaelt man einen anderen COM-Port, wenn man den USB-Anschluss neu einsteckt.

[czcbe]

Ja, COM ist im Gerätemanager vorhanden und sollte ansprechbar sein. Im FHEM sieht man dann kurz INITIALIZED beim CUL und dann schmiert FHEM sofort ab. Bleibt FHEM mal bisschen länger gestartet, erkennt er manchmal immerhin die "VERSION", aber das Reading "update" bleibt bei "no answer". Ich habe auch versch. COM1-4 versucht, versch. Perl-Installationen, läuft immer auf dasselbe raus.
Irgendwo bei der Win32::SerialPort Installation läuft wohl was schief...


Deinen Fehler kann ich so absolut nicht zuordnen. Erscheint diese Error-Meldung im Eventlog?

[Wolfgang Hochweller]

COM : 

Was mir zu COM noch einfaellt : Meinen RFXTRX-Dongle muss ich mit 'NOINIT'  starten, sonst geht nichts.

Fehlermeldung :

Die Fehlermeldung erscheint im Logfile.

Ich sehe, dass die Fehlermeldung in fhem.pl  generiert wird.
Moeglicherweise hat es ja auch etwas mit dem im Windows-Perl fehlenden 'which'-Befehl zu tun,
der beim Start angemeckert wird, aber ohne direkte Folgen.


Eine weitere kommt ab und an aus PERL, ebenfalls im Logfile :

Code: [Auswählen]


PERL WARNING: Terminating on signal SIGHUP(1)