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.
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
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!?
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.
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
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
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.
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):
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).
Die 36_LaCrosse.pm kannst Du nehmen, die ist es definitiv nicht ;D
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
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
Zitat von: HCS am 29 Juni 2015, 22:20:59
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
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
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
Zitat von: Philip am 30 Juni 2015, 16:46:19
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
Zitat von: herrmannj am 30 Juni 2015, 16:58:13
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
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.
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
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 ..
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
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
Hi Philip,
ja super, schön.
Um die Prototype mismatch Meldung einzugrenzen müsste man stacktrace einschalten.
vg
joerg
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
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
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?
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
habs in Handarbeit jetzt erledigt .Trotzdem danke
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?
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.
port 2121 ist von einer anderen Anwendung schon belegt. OWS server ?
vg
joerg
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...
Es _könnte_ mit Umlauten zusammen hängen. Schaum mal hier: http://forum.fhem.de/index.php/topic,33231.msg310724.html#msg310724