fronthem Modulthread

[herrmannj]

Hi,

@herrmannj: wie sieht es denn aus? Kann ich Dir was helfen?

Bin "dran". Leider hält mich der job gut unter Feuer. Ich schau mal das ic die Plots forciere.

vg
joerg

[1of16]

Moin,

mit der Hoffnung, dass ich mich hier an den richtigen Thread anhänge: Ich habe ein kleines (für mich größeres) Problem mit dem fronthem bei der Nutzung von smartvisu festgestellt.
Wenn ich die Smartvisu-Seite über https aufrufe, kommt es zu folgender Fehlermeldung:

Code Auswählen Erweitern

io_fhem.js:166 [io.fhem]: init [V1.10] (address=192.168.1.3 port=2121)
io_fhem.js:423 Mixed Content: The page at 'https://example.com/smartvisu/' was loaded over HTTPS, but attempted to connect to the insecure WebSocket endpoint 'ws://192.168.1.3:2121/'. This request has been blocked; this endpoint must be available over WSS.io.open @ io_fhem.js:423
io_fhem.js:423 Uncaught SecurityError: Failed to construct 'WebSocket': An insecure WebSocket connection may not be initiated from a page loaded over HTTPS.
Das Verhalten ist aber wohl auch nicht unerwartet: https://developer.mozilla.org/en-US/docs/WebSockets/Writing_WebSocket_client_applications#Security_considerations
Ein Ändern auf wss:// bringt leider nicht den gewünschten positiven Effekt, obgleich das wohl möglich sein sollte: https://msdn.microsoft.com/en-us/library/windows/apps/hh761446.aspx?f=255&MSPPError=-2147217396
Ich vermute gerade, dass fronthem schlicht die wss-Anfrage nicht verarbeiten kann?!
Gibt es abgesehen von "deaktiviere die Verschlüsselung" irgendeine Lösungsidee, oder ist dies eher was für die to-do-Liste?

Grüße
1of16

[herrmannj]

Moin,

korrekte Diagnose: deaktiviere die Verschlüsselung (vorerst). Und ja: steht auf der To-do Liste !

Grundsätzlich bin sehr FÜR Sicherheit, Verschlüsselung gehört dazu. Freut mich das Du das sichtlich genau so siehst,

vg
joerg

[1of16]

Moin,

danke für die schnelle Antwort.
Dann bastel ich mir einen kleinen, schicken und unverschlüsselten Umweg, um den "waf" nicht unnötig zu senken
Für halbfertige Sachen zum Testen würde ich dir dann zur Verfügung stehen

Grüße
1of16

[HCS]

Hi,
Bin "dran". Leider hält mich der job gut unter Feuer. Ich schau mal das ic die Plots forciere.

vg
joerg

Hast Du das Thema inzwischen verworfen oder noch auf der Agenda?
Ich überlege inzwischen, ob ich mir eine Lösung baue, um die Charts rüber zu bekommen, so ähnlich wie ich sie von meiner Heizungssteuerung hole.
Mache ich aber nur, wenn Du jetzt nicht sagst "klar, in zwei Wochen ist es fertig"

[herrmannj]

Hi.

Alles gut. Auf der Agenda und in Arbeit. Auf zwei Wochen leg ich mich nicht fest.

Vg
Joerg

[bgewehr]

Ich habe einen Weg gefunden, den Webservice zu killen: per VPN zugreifen und das VPN im Autobahntunnel sterben lassen - das klappt fast immer! Ich mache dann immer einen fhem-Neustart, gibt es noch was besseres? Reanimation am Device oder so?

[herrmannj]

gibt es noch was besseres?

Brücke !!! 

Im Ernst, Danke. Mit der aktuellen Version fällt mir keine alternative Erste Hilfe ein. Steht was im log ? Konkret wäre es interessant ob der websocket stirbt. Wenn ja, steht was in fronthem.err ?

Mit der neuen Version wird das nicht mehr passieren, allerdings leg ich mich noch nicht ein Datum fest. Evtl machts also Sinn das noch patchen wenn möglich.

vg
joerg

[gravidi]

Die Logs würden mich auch intressieren, ich nutze Smartvisu auch über VPN, aber nach verlieren der Verbindung oder manuelles beenden der VPN Strecke bleibt mein Webserver und Fhem erhalten.

[dev0]

Die Logs würden mich auch intressieren, ich nutze Smartvisu auch über VPN, aber nach verlieren der Verbindung oder manuelles beenden der VPN Strecke bleibt mein Webserver und Fhem erhalten.

Bei mir funktioniert es nach einem VPN Verbindungsabbruch ebenfalls korrekt. Meine Vermutung ist, dass die Verbindung vom VPN Gateway zu Fronthem nicht sauber getrennt wird. Ich hatte vor Urzeiten so etwas in der Art schon mal mit einem openVPN beim Kunden.

/Uli

[herrmannj]

passt bei mir auch.

Ist doch aber schön wenn es bei bgewehr anders ist (nicht falsch verstehen) weil: ich möchte ja das fronthem tolerant gegen äußere Fehler ist. "Normal" sollte da ja nichts mehr sein, wenn doch und vlt sogar im log was steht (sprich ich die Ursache verstehe) kann ichs bekämpfen.

Macht fronthem also robuster, ergo ist gut.

vg
jörg

[Morluktom]

Hallo,

ich denke ich habe in 31_fronthemDevice.pm einen Fehler entdeckt:

falsch: (Zeile 465)

Code Auswählen Erweitern

   
$set =~ s/^state// if ($param->{reading} eq 'state');


richtig:

Code Auswählen Erweitern

   
$set =~ s/^state// if ($set eq 'state');


Hintergrund: ich will von einem beliebigen Reading lesen, aber auf ein state schreiben.

[dev0]

Dem kann ich zustimmen. Diese Änderung hatte ich vor längerer Zeit auch schon mal angeregt. Läuft bei mir seit dem ohne Probleme...

[karl0123]

Ich kann auch zustimmen. Der Fehler wurde schon mehrfach gemeldet. Eine Lösung aber für das große fronthem update Ende 2015 versprochen...

[herrmannj]

Ich kann auch zustimmen. Der Fehler wurde schon mehrfach gemeldet. Eine Lösung aber für das große fronthem update Ende 2015 versprochen...

ist wie beim BER 

Ich glaube ich kann das halbwegs nachvollziehen. @dev0: 2 Jahre kann man als ausreichend getestet ansehen. Wenn Du einen patch ins GIT stellst merge ich den.