erste beta - fronthem, smartVISU (closed, Bitte die Anschlussthreads benutzen)

Begonnen von herrmannj, 23 Dezember 2014, 22:36:44

Vorheriges Thema - Nächstes Thema

fidel

Zitat von: herrmannj am 15 Februar 2015, 12:40:08
axo, ja sorry. Ekläre mir das bitte nochmal genauer, ich machs ja gern heile - ich muss es nur verstehen.  :)

vg
jörg
Ich habe in fhem nen dummy mit setlist slider von -80 bis -45.  (Er dient um die Lautstärke meines AVR bei einem Anruf zu setzen.  Den Maximalwert habe ich eben noch geändert.)

In sv habe ich ebenfalls einen slider mit selbem min max Wert.
Im gad editor den entsprechenden dummy ausgewählt reading und cmd set auf state und als converter numdirect.

Das Fehlverhalten ist folgendes.

In fhem hat der dummy den state -60.
Bei Aufruf von sv wird jedoch -45 angezeigt.  Ändere ich in sv auf z. B. auf -58 wird der Wert in fhem im dummy korrekt übernommen und in sv springt der Wert direkt nach einstellen des Wertes wieder auf -45. In fhem bleibt der Wert -58 erhalten.

Grüße Steven
Fhem 5.6 auf Cubietruck,CUL,CUL_TCM97001,FritzBox7390,HMLAN,CUL_HM_HM_OU-16LED,CUL_HM_HM_SEC_SC,CUL_HM_HM_LC_SW4,CUL_HM_HM_RT_DN,HUEBridge,HUEDevice,Panstick,Panstamp (binouts,rgddriver mit dht22),PHTV,Yamaha-AVR,Withings,ELV-IPS, etc...

fidel

Das Verhalten würde ja passen, zu dem was marvin auch schon schilderte.
Wenn fhem bzw.  fronthem den Wert +58 zurück liefert, springt der slider in sv auf -45.
Fhem 5.6 auf Cubietruck,CUL,CUL_TCM97001,FritzBox7390,HMLAN,CUL_HM_HM_OU-16LED,CUL_HM_HM_SEC_SC,CUL_HM_HM_LC_SW4,CUL_HM_HM_RT_DN,HUEBridge,HUEDevice,Panstick,Panstamp (binouts,rgddriver mit dht22),PHTV,Yamaha-AVR,Withings,ELV-IPS, etc...

herrmannj

gut (oder nicht). Das macht Sinn - ich geh auf die Suche woran das liegen könnte. vg jörg

marvin78

Bei mir ist es aber (nur) ein ganz normaler Temperaturwert (jedoch aus unterschiedlichen Devices, aber immer gleich formatiert). Über NumDirect hat das schonmal funktioniert. Nur über NumDisplay noch nie.

cruser1800

Hallo Bernd,

ich habe deine Timecounter etwas angepasst. Jetzt zeigt es auch Stunden an. Weiß zwar nicht ob es elegant ist, aber es funktioniert.

Vielleicht willst du es einbauen!

{% macro timecounter(id, gad, mode) %}

<script type="text/javascript">
function ZeitAnzeigen (objectID, mode, value) {
var absSekunden = value
if (absSekunden == 'NaN') {absSekunden = 1};
var relSekunden = absSekunden % 60;
var absMinuten = Math.abs(Math.round((absSekunden - 30) / 60));
var relMinuten = absMinuten % 60;
var absStunden = Math.abs(Math.round((absMinuten - 30) / 60));
var anzSekunden = "" + ((relSekunden > 9) ? relSekunden : "0" + relSekunden);
var anzMinuten = "" + ((relMinuten > 9) ? relMinuten : "0" + relMinuten);
var anzStunden = "" + ((absStunden > 9) ? absStunden : "0" + absStunden);
return(anzStunden + ":" + anzMinuten + ":" + anzSekunden);
};
</script>
<span id="{{ uid(page, id) }}" data-widget="basic.timecounter" data-item="{{ gad }}" data="{{ mode }}">-:-:-</span>

{% endmacro %}


Gruß Lutz

olli84

Zitat von: herrmannj am 31 Januar 2015, 20:19:57
ja, so werden wir das wohl machen  :) - Du hast ja schon genug Geduld geopfert. Danke. Ich habe (oben) noch 'nen Sack Arbeit dazubekommen, mal schauen ob ich das heute noch schaffe, sonst evtl morgen. Und dann machen wir 'nen neuen fred . vg jörg

Hallo Jörg,

war jetzt, wie du weisst, einige Tage im Urlaub.

Hab nun heute mal ein Update von Fronthem, FHEM und dem driver (v.1.02) gemacht.

Hatte heute mal wieder das zweifelhafte Vergnügen

2015.02.15 18:43:10 1: fronthem: thread ws closed for unknown reason
2015.02.15 18:43:10 3: fronthem: client Olli: forced disconnect


zu begegnen. Hattest du den vermeintlichen Fix für mein Problem schon eingebaut?

Gemacht hatte ich kaum was, ein paar Seiten umgestaltet, Server restartet (Updates von FHEM, Fronthem, usw.) und ein bisschen am PC rumgespielt. Das Tablet war heute aussen vor!

Ich werde das die nächsten Tage mal beobachten und dir eventuelle Wiederholungen melden.

Grüßle,
Olli

trickser

Ich hätte eine Frage.

Ich habe bei mir zuhause ein sicheres Netz und greife gut und gerne auch mal über VPN auf mein Heimnetzwerk zu.
Dabei bin ich aber schon oft dem Problem begegnet das ich nicht mehr auf smartVISU zugreifen kann. Jetzt wäre die Frage ob ich nicht einfach alle Geräte für smartVISU erlauben kann. Auch ohne IP Erkennung. Ich brauche das nämlich für Zuhause nicht wirklich.

Danke im voraus.

herrmannj

Hi oli,

Wenn du das Update hast (kannst ja zur Sicherheit nochmal) dann müssen wir das beobachten. So mit Log, Frontem.err und so.

Hi trickser

Ne geht nicht, weil: geht ja nicht nur um den Access. Die device müssen auch einzeln von Frontem betreut werden. Wer braucht wann welche gad und so. Bzgl Access kannst du ja whitelist auf false setzen, dann musst du nichts weiter machen als das device mit Ip einmal zu definieren.

Vg
Jörg

trickser

Okay danke. Du meinst, wenn ich Whitelist auf false setzte können zumindest die angemeldeten Geräte auf alle Geräte zugreifen ohne das ich vorher die Rechte setzten muss? Oder wie ist das gemeint?

herrmannj

Ja genau. Natürlich musst du die jeweiligen gad einmal definiert haben. Das kannst du auf einem x beliebigen Client machen, das wird geshared.

Dann jeweil am device whitelist false, Client darf alle gad lesen und schreiben.

Vg
Jörg

fidel

Zitat von: fidel am 15 Februar 2015, 16:03:08
Ich habe in fhem nen dummy mit setlist slider von -80 bis -45.  (Er dient um die Lautstärke meines AVR bei einem Anruf zu setzen.  Den Maximalwert habe ich eben noch geändert.)

In sv habe ich ebenfalls einen slider mit selbem min max Wert.
Im gad editor den entsprechenden dummy ausgewählt reading und cmd set auf state und als converter numdirect.

Das Fehlverhalten ist folgendes.

In fhem hat der dummy den state -60.
Bei Aufruf von sv wird jedoch -45 angezeigt.  Ändere ich in sv auf z. B. auf -58 wird der Wert in fhem im dummy korrekt übernommen und in sv springt der Wert direkt nach einstellen des Wertes wieder auf -45. In fhem bleibt der Wert -58 erhalten.

Grüße Steven
Hallo Jörg,

ich habe mich vertan. Der Wert kommt auch beim setzen aus smartVISU als positiv Wert in fhem an.

Gruß
Steven
Fhem 5.6 auf Cubietruck,CUL,CUL_TCM97001,FritzBox7390,HMLAN,CUL_HM_HM_OU-16LED,CUL_HM_HM_SEC_SC,CUL_HM_HM_LC_SW4,CUL_HM_HM_RT_DN,HUEBridge,HUEDevice,Panstick,Panstamp (binouts,rgddriver mit dht22),PHTV,Yamaha-AVR,Withings,ELV-IPS, etc...

kumue

#1526
Funktioniert der Attribute Converter schon ?
Will über SV ein AT je nach Bedarf auf disable 0 bzw. 1 setzten....

Habe im GAD-Editor verschiedenes probiert, aber es hatte keine Auswirkung auf das AT.

Gruß Kai

##################################################
Edit:
Habs hinbekommen.. auch bei reading disable eingetragen und dann gings...

HCS

Ich habe mich mal mit den Charts beschäftigt.

Hier die Grobfassung meiner Gedanken dazu. Details müssen noch ausgearbeitet werden.

Da gibt es einige SV Dinge, die meiner Meinung nach Änderungsbedürftig sind. Da wären (vermutlich noch nicht vollständig die Liste):

- Das GAD wird mit Konfigurationswerten erweitert. Das ist ganz unglücklich.
    Beispiel: wenn man diesen plot definiert:
    {{ plot.period("OilLevelPlot",
                   ["hcs.data.OilLevelPlot"],
                   "avg",
                   "5y 6m",
                   "",
                   "10",
                   "400",
                   "4400",
                   "500",
                   "Füllstand",
                   ["#44f"],
                   ["line"],
                   ["","Liter"]) }}

ist das GAD, das am Schluss dabei rauskommt und bei fronthem ankommen würde und auch wieder geliefert werden muss das hier: "hcs.data.OilLevelPlot.avg.5y 6m.0"
Im trunk von SV gibt es eine neuere Version, die einen weiteren Parameter hat, der auch an das GAD angehängt wird.
Nach einem SV-Update würde dann in fronthem kein definiertes GAD mehr passen.
Ich halte es generell auch nicht für sinnvoll, Konfigurationswerte mit Punkten getrennt, an ein Idetifikationsmerkmal anzuhängen.
-> Dafür habe ich bereits eine Lösung
   
- Man sollte in SV festlegen können, in welchem Interval der Plot aktualisiert wird
-> Lösung vorhanden

Ein plot mit mehreren Serien erscheint nur, wenn alle Serien Daten geliefert haben
-> Vermutlich im Treiber machbar

- Solange ein Plot keine Serie bekommen hat, ist er komplett unsichtbar
-> Vermutlich im Treiber machbar

Es ist nicht vorgesehen, den kompletten Plot zu aktualiseren, sondern nur einzelne Punkte hinten anzufügen
-> Lösung vorhanden, einzelne Punkte anhängen auch machbar

- Die plotoptions der Highcharts können nicht gesetzt werden. Genau da stecken aber viele nette Konfigurationsmöglichkeiten für das chart.
-> Im Widget realisierbar

Man sollte bei der GAD-Definition optional die Klasse für den "Plot-div" setzen können, um z.B. unterschiedlich große charts konfigurieren zu können
-> Im Widget realisierbar

Das läuft aber darauf raus, dass wir das ganze direkt vom Start weg selbst abhandeln. Der Treiber muss das eh, sonst bauen wir "nonblocking" hinterher wieder ein.
Ich habe das mal im Treiber testweise implementiert und versorge ihn von meinem addon-Treiber aus mit Daten.
Von fronthem aus sollte das eigentlich genauso machbar sein.

Der einzig Nachteil: Es geht nicht mit den original SV-Widgets, sondern nur mit angepassten. Für den plot.period habe ich das gemacht.
Ist nicht so dramatisch und es gibt eh nur vier plot Widgets in SV.
Und da wir die Widgets bestimmt erweitern werden, können wir auch direkt mit eigenen starten.
Die wären einfach analog zu den plot.* von SV, nämlich chart.comfortchart, chart.period, chart.rtr, chart.temprose

Die Kommunikation zwischen dem Treiber und fronthem könnte so ablaufen:
fronthem bekommt (analog zu monitor) die Serien mitgeteilt, die es liefern soll
Beispiel:
{
  "cmd": "series",
  "items": [
    {
      "gad": "plot.LivingRoom",
      "mode": "avg",
      "start": "2d",
      "end": "1d",
      "interval": "300"
    },
    {
      "gad": "plot.Cellar",
      "mode": "avg",
      "start": "3d",
      "end": "now"
      "interval": "600"
    }
  ]
}

Das teilt fronthem mit: bitte zwei Serien liefern
das GAD ist "plot.LivingRoom", mode ist "avg", die Serie soll vor zwei Tagen beginnen und vor einem Tag enden und alle 300 Sekunden aktualisiert werden.
Zweite Serie sinngemäß. Ob wir den mode brauchen muss man noch sehen.

fronthem würde die Serien dann in dieser form an den Treiber schicken:
{
  "cmd": "series",
  "items": {
    "gad": "plot.LivingRoom",
    "plotdata": [
      [
        "x-Value1",
        "y-value1"
      ],
      [
        "x-Value2",
        "y-value2"
      ],
      [
        "x-Value3",
        "y-value3"
      ]
    ]
  }
}


Ob da noch Anpassungen für comfortchart, rtr und temprose erforderlich sin, muss ich mir anschauen. Habe bisher nur den period betrachtet.

Das Ganze habe ich testweise mal imlementiert. Beispiel siehe Anhänge.


marvin78

Comfortchart funktioniert auch jetzt und ohne irgendeine Anpassung schon. Der benötigt ja nur 2 AKTUELLE Werte für Temperatur und Humidity. Das muss nichts angepasst werden.

bgewehr

Comfortchart kannst Du weglassen, der funktioniert ja schon im Original. Super Sache, ich freue mich drauf!
FritzBox 7590, Synology DS216+II mit Docker
Docker: FHEM mit hmlan, Homebridge, node-red, mosquitto, ems-collector für Buderus EMS mit AVR Net-IO
Gartenwasser über MQTT auf R/Pi A+
Volkszaehler.org auf R/Pi 2B mit Pi_Erweiterung
Raspberrymatic auf R/Pi 4B mit RPI-RF-MOD u. CUL868