New FHEM Tablet UI

[Brockmann]

Mach doch einen dummy.

Und so bastelt sich jeder Benutzer, der etwas anderen als einen simplen On/Off-Switch integrieren will (bei der Keymatic ist es ja letztlich das gleiche), jeweils ein Dummy und ein paar Notifys, um das zu realisieren?
Also da sollte man lieber direkt durch die UI unterstützen, für set und Statusermittlung abweichende Werte zu verwenden. Das erhöht gleichzeitig die Flexibilität und Benutzerakzeptanz.

[Mitch]

Naja, erstmal, dann programmier doch selber ein UI   

Und das mit dem dummy hab ich ja eher auf dein Thema mit on-for... gedacht, nicht UI speziell.
Und mit Keymatic? Da braucht man keinen dummy, da muss nur die Anzeige des Zustands umgebaut werden.

[Brockmann]

Und mit Keymatic? Da braucht man keinen dummy, da muss nur die Anzeige des Zustands umgebaut werden.

Irgendwie reden wir aneinander vorbei, obwohl wir dasselbe Problem haben:
Du willst an Deine Keymatic ein "set unlock" senden, aber für den Status soll "unlocked" erkannt werden.
Ich will an meinen Lüfter ein "set on-for-timer 300" senden, aber für den Status soll "on" erkannt werden.

Und ja, dafür muss nicht, aber könnte "nur die Anzeige des Zustands umgebaut werden", genau davon rede ich ja. Aber am Besten nichts hart verdrahtetes, sondern konfigurierbar.

[setstate]

Man müsste also quasi data-set-on und data-get-on bzw. data-set-off und data-get-off unterscheiden können. Damit würde sich die Keymatic auch in den Griff bekommen lassen, oder?

Hallo ihr,
genau das schwebte mir auch schon vor,unterschiedliche on/off Werte für get und set. Dort wo es gebraucht wird. Der default wird sein  data-set-on = data-get-on bzw. data-set-off =data-get-off , wenn nicht angegeben.

Baue ich gerne sofort ein, bin aber gerade auf Dienstreise und erst am WE wieder in der Nähe meines FHEM Servers. Wenn es nicht eilt ... Ansonsten müsste ich heute Abend im Hotel versuchen, ungetestet den Codedirekt auf Github zu erweitern.

Viele Grüße
Mario

[Brockmann]

Baue ich gerne sofort ein, bin aber gerade auf Dienstreise und erst am WE wieder in der Nähe meines FHEM Servers. Wenn es nicht eilt ... Ansonsten müsste ich heute Abend im Hotel versuchen, ungetestet den Codedirekt auf Github zu erweitern.

Nee, bloss keinen Stress! So sehr eilt es (mir jedenfalls) nicht.

[setstate]

Derzeit fehlt mir übrigens noch eine gute Idee um Milight-Devices einzubinden. Das Milight-Device hat die Besonderheit, dass es im eingeschalteten Zustand in STATE nicht einfach nur "on", sondern auch die eingestellte Dimmung stehen hat: "on 100", "on 42" etc.

Ein anderes Reading für die Zustandsabfrage gibt es nicht, wo nur on oder off drin steht? Wie sieht das Command zu stetzen aus, muss dort auch der Dim-Value mit rein?

Dimmer Element ist noch in Planung bei mir und es gibt aber auch ein Pull-Request, wo ein User das Thermostat-Control umgebogen zur Steuerung eines Shutters. Das sind aber noch einige Fragen offen.

[nesges]

Ein anderes Reading für die Zustandsabfrage gibt es nicht, wo nur on oder off drin steht? Wie sieht das Command zu stetzen aus, muss dort auch der Dim-Value mit rein?

Standardmässig gibt's keins, ich benutze derzeit für manche Aufgaben ein userReading:

Code Auswählen Erweitern

attr MILIGHT_Zone1_Wohnzimmer userReadings simple_state {my @s=split ' ', ReadingsVal($name,'state','');$s[0]}

Zum Schalten reicht simples on/off. Set kann zwar auch einen zweiten Parameter ("ramptime") annehmen, der hat aber wiederum nichts mit dem Dim-Value zu tun. Daneben haben die Milights noch diverse andere Schaltoptionen, würde ich aber persönlich für Overkill halten die hier zu implementieren.

[Mitch]

@Brockmann: ja, da haben wir aneinander vorbei geredet   

@Mario: keinen Stress, ich habe ein Workaround gefunden. Wenn Du es fertig hast, dann hast Du es fertig. Eine paar Tage oder Woche hin oder her, kein Problem.
Ich finde es sowieso super, wie schnell Du hier Dinge umsetzt und mein "Lieblings-UI" perfektionierst 

[nesges]

Erstmal:

Ich finde es sowieso super, wie schnell Du hier Dinge umsetzt und mein "Lieblings-UI" perfektionierst 

+1

Noch zwei Vorschläge:

1.) Wenn man in fhem-tablet-ui.js in den drei $.ajax-Calls zur Fhemweb-Instanz jeweils die Zeile

Code Auswählen Erweitern

url: "../fhem",
durch

Code Auswählen Erweitern

url: $("meta[name='fhemweb_url']").attr("content")||"../fhem/",
ersetzt, kann man das UI auch ausserhalb von fhem zB in einem Apache betreiben, wenn man einen Meta-Tag "fhemweb_url" mit dem URL zur FHEMWEB-Instanz setzt. Es spricht auch nichts gegen eine andere Maschine - das habe ich allerdings nicht getestet.

2.) Bei mir hat die folgende Änderung an requestFhem() einen kleinen Performanceschub ergeben:

Code Auswählen Erweitern

var d=Array();
$('div[device]').each(function() {
    d.push($(this).attr('device'));
});

$.ajax({
    [...]
    data: {
        cmd: "list " + d.join() + " " + paraname,

Ich führe also nicht mehr "list .* STATE" aus, sondern hole mir zunächst die Liste der tatsächlich verwendeten Devices.

Edit: C&P Fehler korrigiert ("devices" durch "d" ersetzt, da "devices" bereits vergeben ist)

[wex_storm]

Zum Thema aufruf über andere Maschine usw. Da solltet ihr einen Cross-Site-Scripting Fehler bekommen. Man kann das alles wohl einstellen - abe standardmässig sollte das nicht gehen.

Gruß

    Björn

[nesges]

Stimmt!
attr FHEMWEB CORS 1
muss für die angefragte Instanz gesetzt sein

[setstate]

Hallo nesges,

deine heutige Optimierungen bekommen ein +1 von mir 

2) ich kann das zwar z.Zt. nicht nachtesten, aber sehr logisch und sollte was bringen . Ich würde das Devices Array aber beim Start anlegen, nicht jedem mal beim requestFhem() Aufruf immer wieder neu. Bringt zwar nix beim ersten Durchlauf, sind aber weniger Durchläufe bei Wiederholungen.

1) würde grundsätzlich ein Plus an Flexibilität bringen, und per default Out of the box weiterhin funktionieren. Aber wie Björn schon schreibt, reicht dem Browser schon ein anderer Port und er lehnt den Ajax Request ab, mit der Begründung "Cross-Site-Request". Deshalb hatte meine erste Version noch den PHP Aufruf drin, dann funktioniert das auch über einen zusätzlichen Webserver. Siehe mein ersten Commit ./php/send.php. Probiere das mal mit deiner Umgebung aus.

Viele Grüße
Mario

[nesges]

1) würde grundsätzlich ein Plus an Flexibilität bringen, und per default Out of the box weiterhin funktionieren. Aber wie Björn schon schreibt, reicht dem Browser schon ein anderer Port und er lehnt den Ajax Request ab, mit der Begründung "Cross-Site-Request". Deshalb hatte meine erste Version noch den PHP Aufruf drin, dann funktioniert das auch über einen zusätzlichen Webserver. Siehe mein ersten Commit ./php/send.php. Probiere das mal mit deiner Umgebung aus.

Das würde in meiner Umgebung zwar funktionieren, aber grundsätzlich wäre eine Abhängigkeit von PHP doch ein Rückschritt. Von daher war deine Entscheidung den Ansatz nicht weiter zu verfolgen mMn genau richtig. Der optionale Meta-Tag funktioniert dagegen auch in einem statischen HTML-File (grade getestet: einfache meinen kompletten Ordner aus dem Apache auf den Windows-Desktop kopiert, PHP rauseditiert: läuft), braucht nur das gesetzte CORS-Attribut in FHEMWEB und man spart dabei sogar das HTTPSRV-Device in fhem. Oder man benutzt es nicht und alles funktioniert weiter wie gehabt.

[bjoernbo]

Hallo, ich verzweifle gerade an folgender Konstellation.Ich will oben rechts ein Logo als Link einbauen. Der Link soll auf das Dashboard verweisen. Egal wie ich das ganze einfüge, zerschiesst es mir das ganze Layout!

ader>DASHBOARD</header>
<div typw="label"class="cell"><a href ="xxxxxxxxx">Dashboard</div>
</li>

[nesges]

evtl. wegen dem Typo "typw". Falls nicht, zeig bitte mal mehr HTML-Code.
Edit: Oh, da fehlt auch das schliessende </a>