Fronthem und smartVisu - Mit aktueller fhem.pl keine Aktualisierung der Daten

[karl0123]

Mit der fhem.pl der aktuellsten Version bekommt smartVisu aus Fronthem keine Daten mehr. Interessanterweise "denkt" der Treiber, er sei connected und es gibt auch auf der JS-Konsole keine Fehler (egal, wie man das Debugging schraubt). In FHEM stehen alle Devices auf disconnected und es werden auch keine Daten im Frontend angezeigt. Ich habe versucht, alle Infos, die ich bekommen kann, zusammenzutragen und hier zu posten. Man findet jedoch weder im FHEM-Log (verbose 5) noch in der Konsole Hinsweise.

[herrmannj]

das ja doof.

Mach mal bitte einen kompletten fhem Neustart.

Schau mal bitte ins fhem log mit verbose 5 - kannst mir sonst auch epr pm schicken. Am besten fhem aus, log löschen, starten, sv connect und dann log nehmen. So ist dann nur der start mit den relevanten Sachen drin

vg
joerg

[karl0123]

Neustart von FHEM habe ich natürlich durch. Log mit verbose 5 sieht exakt identisch mit der lauffähigen Vorversion aus (ich kann bis Mittwoch Abend kein weiteres machen, habe das aber alles gecheckt - sonst würde ich hier nicht posten). Ich habe einfach ein restore gemacht und alles läuft wieder. Ich bin nicht 100%ig sicher, dass es an der aktuellen fhem.pl liegt, es lässt sich aber durch ein aktuelles Update von FHEM reproduzieren (das Update enthält auch eine neue IODev.pm und viele weitere Neuigkeiten).

Ich denke, hilfreicher als ein Log, dass sich absolut nicht vom Log einer lauffähigen Version unterscheidet, wäre eventuell, dass jemand, der smartVisu verwendet, versucht durch ein Update das ganze nachzuvollziehen!?

[marvin78]

Ich muss sagen, dass ich das selbe Problem auch festgestellt habe. Es liegt aber weder an der aktuellen fhem.pl noch an der DevIo.pm. Ich habe mein update aus anderen Gründen (Homematic spielt in der aktuellen Version völlig verrückt) wieder restored, jedoch einige updates einzeln eingespielt. fhem.pl und DevIo.pm sind bei mir aktuell und smartVisu erhält Daten. Als ich allerdings das komplette Update vor dem restore getestet habe, hatte ich das selbe Problem mit smartVisu wie karl0123. Eventuell gibt es irgendwelche Wechselwirkungen. Ich kann das leider aktuell nicht genauer untersuchen.

[avg123-de]

Hallo zusammen,

ich hatte vorgestern das selbe Problem. Ich hatte ein Update von FHEM durchgeführt und danach habe ich in SV keine Werte mehr angezeigt bekommen und schalten ging natürlich auch nicht.
Habe daraufhin einfach wieder den alten Stand eingespielt (damit läuft's perfekt ). Woran es lag hatte ich aber nicht näher untersucht.

viele Grüße
Alexander

[herrmannj]

Na dann muss ich da wohl ran.

Ihr (marvin, Alexander) seid erst mal versorgt, Karl ist beim Angeln. Ich muss mich also nicht überschlagen ?

vg
joerg

[HCS]

Ich habe gerade ein Update gemacht, und es funktioniert noch wie gehabt, sowohl auf den Tablets als auch am MacBook
Da scheinen also bestimmte Gegebenheiten erforderlich zu sein.

[marvin78]

Ich habe auch den Eindruck, dass irgendein Modul Probleme macht, welches nicht jeder verwendet. Da ich aktuell keine Zeit habe, das näher zu untersuchen, wäre eventuell eine Suche nach Gemeinsamkeiten hilfreich. Folgende Module sind vor dem Restore bei mir aktualisiert worden (nur die verwendeten):

Code Auswählen Erweitern

UPD ./fhem.pl
UPD FHEM/00_HMLAN.pm
UPD FHEM/01_FHEMWEB.pm
UPD FHEM/10_CUL_HM.pm
UPD FHEM/31_LightScene.pm
UPD FHEM/32_yowsup.pm
UPD FHEM/33_readingsGroup.pm
UPD FHEM/34_NUT.pm
UPD FHEM/36_LaCrosse.pm
UPD FHEM/72_FB_CALLLIST.pm
UPD FHEM/72_FB_CALLMONITOR.pm
UPD FHEM/72_FRITZBOX.pm
UPD FHEM/91_notify.pm
UPD FHEM/93_DbLog.pm
UPD FHEM/98_HMinfo.pm
UPD FHEM/98_backup.pm
UPD FHEM/98_dummy.pm
UPD FHEM/98_statistics.pm
UPD FHEM/DevIo.pm
UPD FHEM/HMConfig.pm
UPD docs/commandref_frame.html
UPD docs/commandref_frame_DE.html
UPD www/pgm2/console.js
UPD www/pgm2/fhemweb.js

Vielleicht hat ja auch jemand direkt im Auge, welches der Module überhaupt Probleme machen könnte (im Zusammenhang mit Fronthem).

[HCS]

Die 36_LaCrosse.pm kannst Du nehmen, die ist es definitiv nicht 

Was ich grob überflogen nicht verwende:
UPD FHEM/00_HMLAN.pm
UPD FHEM/10_CUL_HM.pm
UPD FHEM/31_LightScene.pm
UPD FHEM/32_yowsup.pm
UPD FHEM/34_NUT.pm
UPD FHEM/72_FB_CALLLIST.pm
UPD FHEM/72_FB_CALLMONITOR.pm
UPD FHEM/72_FRITZBOX.pm
UPD FHEM/98_HMinfo.pm
UPD FHEM/HMConfig.pm

[herrmannj]

Generell habe ich fronthem so designed das es so unabhängig wie möglich von anderen fhem modulen (devio, fhemweb, tcp, etc) ist.

fhem.pl wäre möglich (ist ja core, darf also auch).

Bin also mal gespannt. Ich bin aber doch optimistisch das ich den logs etwas entnehmen kann wenn ich welche bekomme. Bei Verbose 5 landet die gesamte Kommunikation zum smartVisu im log. Das muss ja etwas "anders" sein  - sonst würde es ja gehen.

Wenn ich raten müsste würde ich auf den import das json moduls in einem anderen fhem modul tippen, bzw das json dort "anders" importiert wird. Aber wie gesagt, mit log müsste sich das schon systematisch eingrenzen lassen.

vg
jeorg

[dev0]

Was ich grob überflogen nicht verwende:

In meinen Installationen tritt auch kein Fehler auf. Dann können wir die Module ggf. noch weiter eingrenzen:

UPD FHEM/32_yowsup.pm
UPD FHEM/34_NUT.pm
UPD FHEM/72_FB_CALLLIST.pm
UPD FHEM/72_FB_CALLMONITOR.pm
UPD FHEM/72_FRITZBOX.pm

[Philip]

Moin zusammen,

bei mir das selbe Problem. Keine Werte in Smartvisu nach dem Update.

In den Logs bekomme ich folgende Fehler beim Neustart von FHEM:

2015.06.30 16:30:46 1: Including ./FHEM/myCONF/20_FRITZBOX.cfg
Prototype mismatch: sub main::decode_json: none vs ($) at /usr/lib/perl5/5.12.1/Exporter.pm line 64, <> line 5.
at (eval 980) line 1
Prototype mismatch: sub main::to_json ($@) vs ($) at /usr/lib/perl5/5.12.1/Exporter.pm line 64, <> line 5.
at (eval 980) line 1
Prototype mismatch: sub main::from_json ($@) vs ($) at /usr/lib/perl5/5.12.1/Exporter.pm line 64, <> line 5.
at (eval 980) line 1
defined(%hash) is deprecated at /usr/lib/perl5/vendor_perl/5.12.1/SOAP/Lite.pm line 465, <> line 5.
        (Maybe you should just omit the defined()?)
defined(%hash) is deprecated at /usr/lib/perl5/vendor_perl/5.12.1/SOAP/Lite.pm line 2203, <> line 5.
        (Maybe you should just omit the defined()?)
2015.06.30 16:30:46 1: Including ./log/fhem.save
2015.06.30 16:30:46 1: configfile: Unknown command alias, try help.
Unknown command alias, try help.
2015.06.30 16:30:46 1: ActionDetector:alive:1 dead:0 unkn:0 off:0

und später:

ipc fronthem:127.0.0.1:34329 (ws): error JSON::XS::to_json has been renamed to encode_json, either downgrade to pre-2.0 versions of JSON::XS or rename the call at ./FHEM/01_fronthem.pm line 290
decoding ipc msg {"connection":"conn-KyGhK7Dt","sender":"192.168.1.251","identity":"unknown", "message":{"cmd":"monitor","items":[<<<alle meine GADs >>>]}}
JSON::XS::to_json has been renamed to encode_json, either downgrade to pre-2.0 versions of JSON::XS or rename the call at ./FHEM/01_fronthem.pm line 290

Ich denke, da ist was in JSON deprecated.

Grüße,

Philip

[Philip]

Nochmal ich... 

Habe in 01_fronthem.pm alle "to_json" durch "encode_json" und alle "from_json" durch "decode_json" ersetzt.

Jetzt klappt es wieder.

Grüße,

Philip

[herrmannj]

Nochmal ich... 

Habe in 01_fronthem.pm alle "to_json" durch "encode_json" und alle "from_json" durch "decode_json" ersetzt.

Jetzt klappt es wieder.

Grüße,

Philip

Kann sein das damit den utf8 support kappst. Probier mal bitte "öäü" in beide Richtungen. (dummy und direct converter)

vg
Jörg

[Philip]

Kann sein das damit den utf8 support kappst. Probier mal bitte "öäü" in beide Richtungen. (dummy und direct converter)

Jupp, hast recht. Kommt in beide Richtungen nur Gehacktes an.

Übrigens: UZSU's können seit dem Update auch nicht mehr angelegt werden:
2015.06.30 17:01:59 1: workstation: error doing $result = fronthem::UZSU($param); encountered object '1', but neither allow_blessed nor convert_blessed settings are enabled at ./FHEM/99_fronthemUtils.pm line 83

Grüße,

Philip

[herrmannj]

jut.

Problem sind ein inkompatibler include des json moduls in einem anderen fhem modul.
Hast Du schon herausbekommen welches ? Ich denke mal das wird eines aus der fb Familie sein. Workaround könnte evtl (!) darin bestehen dort use JSON::XS in use JSON zu ändern.

Erst mal nur workaround, ich schau mir fronthem an wie ich das immun machen kann.

Da ich JSON verwende und das wiederum je nach Verfügbarkeit auf JSON:XS ider JSON:PP aufsetzt sollte es eigentlich keine Konflikte geben. Soltte .... (seufz)
Mal schauen was ich dazu finden kann ....

vg
joerg

EDITH: um da nicht mißverstanden zu werden: da ist natürlich nicht das "andere Modul" verantwortlich, das muss ich in fronthem lösen.

[Philip]

jut.

Problem sind ein inkompatibler include des json moduls in einem anderen fhem modul.
Hast Du schon herausbekommen welches ? Ich denke mal das wird eines aus der fb Familie sein. Workaround könnte evtl (!) darin bestehen dort use JSON::XS in use JSON zu ändern.

Jupp, 72_FRITZBOX.pm scheint der Verursacher zu sein.

Ersetze dort in Zeile 52

eval "use JSON::XS;1" or $missingModulWeb .= "JSON::XS ";

durch

eval "use JSON;1" or $missingModulWeb .= "JSON ";

und lasse in 01_fronthem.pm alles beim alten.  (mit "to_json" und "from_json")

dann ist alles schön - inklusive Umlaute und USZU.

Beim nächsten Update von 72_FRITZBOX.pm fährt es natürlich wieder gegen die Wand.

Viele Grüße,

Philip

[herrmannj]

ich immunisiere fronthem dagegen - habe auch schon eine idee wie.

vg
joerg

edith: wäre auch möglich das im fb modul durch den workaround oben Nebenwirkungen entstehen, normal sollte es aber laufen weil JSON als wrapper arbeitet.
Nur als disclaimer ..

[herrmannj]

als quick-fix schlage ich im ersten Schritt vor in fronthem und fronthemDevice

"to_json" und "from_json"

mit dem expliziten Package Namen, also:

"JSON::to_json" und  " JSON::from_json"

aufzurufen. Mag mal jemand testen ob dann FB mit JSON::XS wieder passt ?

In der nächsten Version würde ich dann einen wrapper in fronthem einbauen um das zu kapseln und auch den convertern passende JSON Routinen zur Verfügung zu stellen. Innerhalb des wrappers würde ich dann auch auf diverse Sondersituationen in Bezug auf perl version, os und JSON Modul reagieren.

Leider ist perl in Bezug auf die JSON Konvertierung mehr als zickig. Das hängt speziell mit der utf8 Behandlung zusammen und damit was perl für ut8 (noch mal nach byte- und charstream unterteilt) hält.

Danke und vg
joerg

[Philip]

als quick-fix schlage ich im ersten Schritt vor in fronthem und fronthemDevice

"to_json" und "from_json"

mit dem expliziten Package Namen, also:

"JSON::to_json" und  " JSON::from_json"

aufzurufen. Mag mal jemand testen ob dann FB mit JSON::XS wieder passt ?

Hi Jörg,

schaut gut aus! Mit der von Dir vorgeschlagenen Änderung klappt es mit FB. Wenngleich FHEM beim Start eine Fehlermeldung ausgibt.

Code Auswählen Erweitern

2015.06.30 21:36:23 1: Including ./FHEM/myCONF/20_FRITZBOX.cfg
Prototype mismatch: sub main::decode_json: none vs ($) at /usr/lib/perl5/5.12.1/Exporter.pm line 64, <> line 5.
at (eval 980) line 1
Prototype mismatch: sub main::to_json ($@) vs ($) at /usr/lib/perl5/5.12.1/Exporter.pm line 64, <> line 5.
at (eval 980) line 1
Prototype mismatch: sub main::from_json ($@) vs ($) at /usr/lib/perl5/5.12.1/Exporter.pm line 64, <> line 5.
at (eval 980) line 1
defined(%hash) is deprecated at /usr/lib/perl5/vendor_perl/5.12.1/SOAP/Lite.pm line 465, <> line 5.
        (Maybe you should just omit the defined()?)
defined(%hash) is deprecated at /usr/lib/perl5/vendor_perl/5.12.1/SOAP/Lite.pm line 2203, <> line 5.
        (Maybe you should just omit the defined()?)

Die betrifft aber wohl FRITZBOX.pm und soll vermutlich nicht unsere Baustelle sein.

In der fronthemDevice konnte ich allerdings keine Vorkommen mit to_ und from_ finden.

Grüße,

Philip

[herrmannj]

Hi Philip,

ja super, schön.

Um die Prototype mismatch Meldung einzugrenzen müsste man stacktrace einschalten.

vg
joerg

[justme1968]

frontem ist glaube ich nicht das einzige modul das durch das JSON:XS gerade probleme hat.

ich denke wir sollten versuchen zwei dinge zu tun:
den fritzbox maintainer auf use JSON umzustimmen. das sollte eigentlich sowieso die flexiblere variante sein.

und einen allgemeinen wrapper zu bauen der die fritzbox erkennung und behandlung kapselt und vor allem das manchmal noch vorhandene utf8 problem löst. inzwischen gibt es schon eine ganze reihe module die JSON verwenden und die davon profitieren würden.

zur utf8 geschichte hatte ich schon eine vermeintliche lösnung gefunden. leider scheitert es daran das perl das tatsächlich verwendete interne encoding scheinbar zum teil nicht vorhersagbar auswürfelt und es mit fhem immer dann ein problem gibt wenn die utf8 codierten und als solche markierten perl strings mit den zwar auch utf8 kodierten aber nicht als solche markierten fhem strings aufeinander treffen.

gruss
  andre

[herrmannj]

naja, FB (glaube JoeWiemann macht das ?) macht ja nix falsch, ist alles absolut konform. Schöne Abfrage, btw, mit dem eval für "use.."

Insofern finde ich das auch gut das es aufpoppt den generell kannst Du ja für die Zukunft auch nicht ausschließen das ein Autor das so umsetzt oder, schlimmer noch, irgendeine Abhängigkeit JSON::XS importiert. Muss, mMn also jeder für sich lösen.

Die Inkonsistenzen in den JSON modulen plus das bekloppte (sorry) UTF8 handling von perl hat mich auch einige Zeit gekostet. Aber wem sag ichs .

Das utf8 flag in den Perl Strings sagt, entgegen landläufoger Meinung, nicht ob es ein utf8 String ist, sondern nur ob perl Zeichen > 255 in dem String transportiert. Was im übrigen bei utf8 byte streams (2 x byte pro char) überhaupt nicht greift aber eben eine andere JSON Behandlung braucht.

Von daher bin ich wenig optimistisch das in einen generellen (modul - übergreifenden) wrapper zu packen weil gar keine Automatik existiert die das coding zweifelsfrei feststellen kann. Sprich: kannst Du eigentlich nur als Autor wissen wo, wann, welche Codierung im Modul ist. Alleine das gedanklich runter zu brechen ist ja schon echter Sport

vg
joerg

[andrece]

Hallo Zusammen

habe probleme bei Installaltion Fronthem bei "curl -L https://cpanmin.us | perl - --sudo App::cpanminus"

es kommt immer nur

siehe anhang

weiß
jemand rat?

[herrmannj]

Hi

schau mal in die angegeben logs, da wird irgendein Tool fehlen.

Der angegebene Weg funktioniert meist und ist dann am einfachsten

Es gibt im web diverse Anleitungen um cpan (oder cpanminus) zu installieren. Das ist der Installer für perl module. Du kannst also im Zweifel auch alternative Tutorials abhängig von Deinem OS probieren.

cpan um perl module zu installieren: das fragt Dich mehr ab
cpanminus: macht viele Sachen automatisch, meist einfacher

vg
joerg

[andrece]

habs in Handarbeit jetzt erledigt .Trotzdem danke

[Joker]

Also bei mir funktioniert smartVISU mit fronthem aktuell nicht mehr. Ist schon eine Weile so, hab aber keine Zeit gehabt bisher es mir anzuschauen. Es werden keine Werte mehr angezeigt.

Jetzt weiß ich aber nicht, ob ich das hier beschrieben Problem habe oder nicht, wie kann ich das rausfinden? fronthem.err ist leer. Ich habe die to/from json Aufrufe mit dem expliziten Package name ergänzt.

Gibt es irgendwo vielleicht eine korrigierte Version bzw. kann man die aktuelle Entwicklungsversion irgendwo beziehen?

[Joker]

Ich habe jetzt folgendes im FHEM Log gefunden:

Code Auswählen Erweitern

2015.07.14 23:40:44 3: ipc myfronthem:127.0.0.1:36088 (ws): ws alive with pid 4490
2015.07.14 23:40:44 1: ipc myfronthem:127.0.0.1:36088 (ws): ws could not open port 2121
2015.07.14 23:40:44 1: myfronthem: thread ws closed for unknown reason

Was kann das sein? Ist auch nach FHEM Neustart wieder da.

[herrmannj]

port 2121 ist von einer anderen Anwendung schon belegt. OWS server ?

vg
joerg

[Joker]

Ne auf dem Raspberry läuft außer FHEM nichts weiter... ich habe die letzten Wochen auch rein gar nichts am System verändert, von FHEM Updates mal abgesehen.

Jetzt habe ich gestern den Pi einmal durchgebootet, dann war alles wieder OK.

Allerdings, heute Abend ging dann schon wieder nichts mehr  Ich habe das FHEM Log durchforstet und das hier gefunden:

Code Auswählen Erweitern

2015.07.17 01:15:43 1: myfronthem: thread ws closed for unknown reason

Irgendwas ist da neuerdings los... bis vor ein paar Wochen lief das System wochenlang stabil bei mir...

[dev0]

Es _könnte_ mit Umlauten zusammen hängen. Schaum mal hier: http://forum.fhem.de/index.php/topic,33231.msg310724.html#msg310724