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

Begonnen von karl0123, 29 Juni 2015, 10:49:31

Vorheriges Thema - Nächstes Thema

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

Zitat von: herrmannj am 30 Juni 2015, 17:20:06
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

Zitat von: herrmannj am 30 Juni 2015, 20:41:45
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.
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
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

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


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:
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  :P Ich habe das FHEM Log durchforstet und das hier gefunden:

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...