FHEM Forum

Hallo Community,
da ich bei Google nichts gefunden habe Frage ich nun hier:
Unterstützt eines der beiden Visus (SmartVisu: http://smartvisu.de/ oder CometVisu: http://www.cometvisu.com oder vll. gibt es auch andere Visus die ich nicht kenne?) FHEM?
Beziehungsweise, gibt es eine Anleitung dazu, wie man diese kompatibel machen kann?
Ich versteh gerade mal ein wenig von html & php darum wird es für mich schwer sein, Erweiterungen/Driver zu machen.
Ich hoffe ihr könnt mir mehr Auskunft geben.
Lg,
Tropaion

EDIT:
Ein Projekt wurde zu diesem Thema von herrmannj gestartet und befindet sich jetzt in der Alpha-Phase.
Fragen und Diskussion dazu in diesem Thread.
Vor kurzem wurde eine Wikiseite erstellt, die ständig aktuallisiert wird: http://www.fhemwiki.de/wiki/Fronthem

ich kann dir leider nicht weiterhelfen, würde mich aber auch interessieren...

Hi,

SmartVisu sieht ganz ansprechend aus. Erschreckend nur; mit doku haben die das ja noch weniger als ich  ;)

Soweit ich das sehe kann man da driver (als js) einbinden. Das System lässt sich wohl mit widgets erweitern.

Da ich sowieso gerade auf der Suche nach einem neuen Frontend bin kann ich mir gut vorstellen einen fhem driver dafür zu schreiben. Kennt sich vielleicht jemand mit dem System aus ? Also wie genau erstellt man denn da eigene Seiten ? nginx mit php reichen aus ? (das smarthome.py braucht man nicht ?) Wie konfiguriert man denn das ding  ;) ?

vg
jörg

die lizenz ist gpl. das wär ok.

Hallo hermannj,
wenn du das wirklich machen willst fände ich das echt super, unda wahrscheinlich nicht nur ich,
es gibt einige die sich ein schöneres Fronted wünschen und das ist wirklich schön.
Ein guter Freund von mir hat das im Einsatz bei seiner knx Steuerung und das sieht einfach fabelhaft aus.
ich werde so gut ich kann dir helfen denn treiber zu schreiben so weit es in meinem möglichkeiten ist.
Wenn du fragen zum System hast kann ich ihn mal fragen was er dazu weis,
lg,
Tropaion

ZitatWenn du fragen zum System hast kann ich ihn mal fragen was er dazu weis,

Ja, das wäre schön. Kleiner Vorcheck.  ;)

vg
Jörg

Was für Informationen brauchst du denn genau?
Das ich alles schön zusammenschreiben kann.
Vll meldet er sich dann auch hier im Forum.
Lg,
Tropaion

Ich muss auch sagen, die Darstellung von SmartVisu gefällt mit sehr gut...über eine solche Lösung wäre ich sehr dankbar...habe aber leider keinerlei Programmierkenntnisse!

Hi,

ZitatIch muss auch sagen, die Darstellung von SmartVisu gefällt mit sehr gut...über eine solche Lösung wäre ich sehr dankbar...habe aber leider keinerlei Programmierkenntnisse!

Dann kommst Du damit nicht weit. Die Oberfläche musst Du selber per programmieren anpassen (php, html, js ... ). Dazu habe ich gerade diesen (im besten Fall besonders kreativen) Hinweis Text auf deren Webseite entdeckt:
(http://forum.fhem.de/index.php?action=dlattach;topic=27291.0;attach=19332)

Das hat schon ein schales "Geschmäckle", die source ist gpl, aber die Doku haben wir mal hinter einem paywall versteckt  :-\ Zumal die sich jetzt weder bei den releases noch beim support überschlagen. Die Integration in fhem braucht einen hohen zweistelligen Stundenbetrag. Am Anfang steht erstmal reverse engeneering am source code (für 49,- die doku 3 Monate zu mieten sehe ich nicht ein, prinzipiell nicht).

Vielleicht gibt es ja noch Alternativen mit etwas kooperativen Autoren.

vg
Jörg

Wo steht das? Ich finde das nirgends.
Wenn ich auf Doku klicke seh ich die normale Doku. Und wenn es wirklich so ist, kann man die sich ja noch speichern bevor sie gesperrt wird.
Als alternative kenn ich nur noch CometVisu, finde ich auch sehr schön. Ist halt noch ganz neu.
Lg,
Tropaion

nnaja, stimmt. Hinter dem paywall liegt die "kurzanleitung". trotzdem befremdlich

vg
jörg

Cometvisu scheint relativ "einfach" in fhem zu integrieren zu sein!

http://www.cometvisu.de/wiki/index.php?title=CometVisu/Protokoll_(Deutsch)


Edit: die Performance von Cometvisu ist auf meinem ipad2 allerdings unerträglich ( zumindest fuer mich!)

relativ  ;)

smartvisu scheint mit ansprechender, außerdem halte ich das Konzept mit den widgets für sehr wichtig. So Konzepte wie Wecker etc müssten ja per widget realisiert werden. Anbindungstechnisch braucht man einen Treiber auf Seiten der visu und einen auf Seiten von fhem. Bei Smartvisu wäre das wohl über websockets machbar. Würde nur gern erstmal das widget Konzept verstehen...

Denk am Ende wird sich das nicht so dolle vom Aufwand her unterscheiden. Irgendwann in den kommenden Tagen werde ich mal einen pi recyceln und mal eine Testinstallation plus poc machen - mal sehen was geht.

vg
jörg

Sehr schön ich hefte mich mal an diesen Thread an! ;-)

ist es nicht sinnvoller die energie in die existierenden möglichkeiten zu stecken die fhem bietet statt durch irgendwelche schnittstellen zu anderen oberflächen reibungsverluste und probleme zu schaffen?

fhemweb lässt sich mit stylesheets, dashboard, mehr spalten layout und readingsGroup & co schon sehr weit zu einem aussehen wie z.b. smartvisu oder ähnlichem konfigurieren.

natürlich geht noch nicht alles. was fehlt sind z.b. popups um timer zu konfigurieren. aber auch das ist auf basis der bestehenden oberfläche durch aus möglich.

im screenshot sieht man was in einer stunde möglich ist ohne tief in fhem einzugreifen. wenn man das mit schönen stylesheets wie sie sandra z.b. für das ios6 layout gemacht hat und und statt schnittstellen zu anderen oberflächen ein paar neuen widgets für die popups und ein paar anderen erweiterungen kombiniert kommen wir glaube ich viel weiter.   

gruss
  andre

ps: das soll nicht schon wieder kritik am enthusiasmus sein etwas neues zu tun. aber ich finde es schade wenn immer nur etwas neues gemacht wird das dann am ende nur hinter her hinkt weil es aufgepfropft ist statt mit der gleichen energie die bestehenden möglichkeiten zu nutzen und zu erweitern und zu verbessern.

es ist auch jetzt schon sehr viel mehr möglich als die nicht sehr sexy aussehende grüne default ansicht vermuten lässt.

Das Bild kann ich nicht ansehen, keine Rechte.
Was mich beim FHEM-Design z.B. sehr stört, ist das bei mir am Handy (iPhone5s) oder auch am iPad longpoll nicht funktioniert.
Desweiteren ist das Design wirklich nicht besonders schön

Naja irgendwie hat André ja recht, aber ich finde fhemweb einfach zu oldschool oder sogar Retro! Nicht falsch verstehen, aber Dashboard und ReadingsGroup können da nur bedingt helfen wobei die Konfiguration auch schon Tage rauben kann wenn man Anfaenger ist!? Ich bin schon drauf und dran meine angestaubten PHP Kenntnisse zu reaktivieren und ein sehr sehr einfaches (apple like) Frontend zu basteln! Das wichtigste fuer mich ist Einfachheit und Schnelligkeit! Wenn ich mir schon die Probleme mit dem js Geraffel angucke die kaum noch einer versteht glaube ich das ein Neuanfang vielleicht der richtige Weg ist! Fhem als backend, fhemweb als Konfigurationsoberflaeche und eine sexy GUI mit modernen Technologien das wäre fuer mich der Hit in Tueten!

ich hab mich ernsthaft hingesetzt und wirklich viele (viele) Stunden Vorarbeit geleistet um PGM2 dynamische widgets beizubringen (good news: das war nicht ganz umsonst, Teile sind re-usable). Als ich das Framework soweit hatte das ich an livetests gehen konnte haben -> Ende Gelände.
Longpoll bricht ab, fhemweb hängt Minutenlang autistisch vor sich hin, etc.

Dann hab ich versucht das in fhemweb zu debuggen: fazit, fhemweb ist so "verbastelt", da läst sich auch mit vernünftigem Aufwand nix reparieren. Nonblocking und blocking calls sind lustig gemischt, die strukturierung passt hinten und vorne nicht. Ständigen Hilferufe hier im Forum ( bzgl performance) kommen ja auch irgendwo her. Ehrlich, ich habs versucht. Fazit Neustart (!). Fhem ist so cool, das darf (und muss) man auch leben  ;D

vg
Jörg

ja es gibt longoll probleme und die müssen gelöst werden. aber wie soll an ein backend das probleme hat ein neues frontend angebunden werden ohne vorher das backend zu reparieren? und wenn ich mir die smartvisu demo anschaue ist es mit flackern focus problemen aber bei weitem nicht optimal.

welches design meinst du? versuch noch mal das bild anzusehen. auch wenn es nicht perfekt ist schaut es sehr viel mehr nach smartvisu aus als nach default fhem.

jede oberfläche die nicht wirklich mit fhem integriert ist sondern nur über schnittstellen angebunden ist und nicht von der mehrheit verwendet wird, wird das problem haben das sie immer hinter her hinkt und oft für neue devices oder neue fhem module angepasst werden muss. das sieht man jetzt schon an den iphone oder android anwendungen und an den diversen web oberflächen die immer mal wieder auftauchen. es werden regelmässig nicht alle in fhem möglichen devices unterstützt.

warum fhemweb zum konfigurieren und ein modernes gui für den rest? wenn es etwas modernes gibt sollte es doch damit mögliche ein das bisschen konfiguration auch zu machen.

wie gesagt. es soll nicht negativ rüber kommen aber 'apple like' ist nicht auf die schnelle gemacht. da stecken hunderte von entwicklern monate und jahre lang nur am user interface. von der infrastruktur dahinter ganz zu schweigen. das 10te interface für fhem zu basteln das dann einfach und schnell und sexy und für anfänger und fortgeschrittene geeignet ist aber aus welchen gründen auch immer von nur 3 anwendern verwendet wird und nach einer weile einschläft hilft nicht sondern ist schade um den aufwand. mit der gleichen energie 10 dinge am alten interface umgebaut bringt unterm strich glaube ich mehr.

das jetzige interface kann mehr als es auf den ersten blick vermuten lässt.

Ja, du hast schon recht, aber bei dem Standard-GUI gibt es wirklich einige Sachen die mich stören.
Wie z.B
- Longpoll
- Smartphone/Tablet GUI (Ich würde gerne mit meinem alten iPad eine Statusanzeige/Bedienfläche machen, das kann man jedoch vergessen, longpoll geht nicht und auch die GUI sieht echt nicht toll aus (und die App ist auch nicht besser)
- Es gibt keine Zusatzprogramme/Widgets wie NAS-Anbindung oder Telefonliste/Anrufsliste
Natürlich gebe ich die Recht, das das für 3 Leute sinnlos ist. Was mich jedoch wundert ist das es nirgends alternativ GUIs aufzufinden sind. Ich hab im Forum schon des öfteren die Unzufriedenheit mit der GUI mitbekommen
Lg,
Tropaion

ich sehe die Risiken auch und habe mich lange geweigert Arbeit in ein neues Frontend zu stecken. Nur irgendwann muss es eben manchmal sein - dann ist die Anbindung eines existierenden Frontends doch von allen Übeln das kleinste  ;)

vg
Jörg

wie gesagt: longpoll muss repariert oder ersetzt werden.

telefon oder anruferliste gibt es für die fritzbox. die könnte man sicher generalisieren.

was genau meinst du mit nas anbindung?

es gibt sicher 10 alternative guis und mindestens so viele. ankündigungen. und das problem ist jedes mal genau das oben beschriebene. keine anwender. nicht alle devices. wenig entwickler. sie reihenfolge und -abhängigkeiten kannst du den aussuchen :)

gruß
  andre

ZitatNatürlich gebe ich die Recht, das das für 3 Leute sinnlos ist. Was mich jedoch wundert ist das es nirgends alternativ GUIs aufzufinden sind. Ich hab im Forum schon des öfteren die Unzufriedenheit mit der GUI mitbekommen

Naja, Versuche gab es. Die Risiken hat Andre ja gut beschrieben (wobei Risiko == Chance  :) ). smartVisu hat jetzt schon den Vorteil das es eine Gemeinde gibt die es schon einsetzt und widggets für Heizung, RGB, Clock, Wetter usw alle schon da sind - und die KNX Leute basteln ja auch. Da sind schon mal Synergien drin (hoffe ich)

Schauen wir halt erstmal ob es irgendwo showstopper gibt, dafür folgt der poc

vg
jörg

Man kann es ja wie ein GUI fork sehen um sich "frei" zu bewegen um etwas neues zu schaffen! Das ist ja bei vielen OpenSource Projekten durchaus schon gelungen um zu zeigen was möglich ist wenn man ein paar alte Waende einreißt. Mir fiel eben ein, dann eigentlich alle neuen Frontends am besten mit einer DB klar kommen würden ( winke an Betateilchen) dann könnte man die Entwicklung kapseln. Einmal den generischen Weg über fhem und dann parallel einen neuen Frontend der sich im ersten Schritt nur um kernaufgaben beschränkt. ich denke das wird auch dem Performance Problem und die Perl Angst vieler Programmierer abwenden!?

Sauber gekapselt wäre ja eine API die direkt auf FHEM (telnet/json) aufsetzt und Struktur (wie was für Geräte existieren) und Daten (Tempertatur und Status) sauber trennen. Eventuell mit einer Message Queue wie MQTT.

Man muss aber dazu sagen, dass es ja bereits genug Ansätze dafür in FHEM gibt, so gibt es zB eine (Java) REST API, die JSON Calls und die Möglichkeit Befehle einfach über einen GET Call abzusetzen.

Was eher interessant wäre: kennt jemand eine standardisierte API mit der zB ein Web-Interface mehrere Home Automation Server unterstützt (außer Openremote)

es gibt hier: http://forum.fhem.de/index.php/topic,26807.msg202874.html#msg202874 (http://forum.fhem.de/index.php/topic,26807.msg202874.html#msg202874) auch gerade die idee etwas über mqtt zu machen. vielleicht wäre eine generische fhem/mqtt schnittstelle noch für einiges mehr interessant.

gruss
  andre

Hi,

vielen Dank, wie meinst Du das im Zusammenhang mit den visu ? Ich seh den Bezug nicht sofort (sorry). Denkst Du daran die visu mit einem mqtt client auszustatten und fhem passende schnittstellen mitzugeben ?

vg
jörg

bei smartvisu bin ich immer noch der meinung das wir alles was design angeht in fhem mit den bisherigen mitteln minntestens so gut können und es nicht mehr aufwand ist. erst recht nach dem ich mich mal durch alle demos geklickt habe. da fallen dann noch einige unschönheiten auf.

das longpoll problem gibt es auf fhem seite aber ich glaube auch hier das es sich lösen lässt. zumal je nach tatsächlicher anbindung es auch für die schnittstelle relevant ist.

ob mqtt tatsächlich im smartvisu kontext eine rolle spielen könnte weiss ich noch nicht. es ist mir nur in den letzten tagen ein paar mal aufgefallen. nicht nur hier im fhem forum. und wenn schon schnittstelle dann so generisch wie es geht.

gruss
  andre

ah, verstehe. thnx.

Das Thema ist bei den Visu ja nicht ein bestimmtes Design mit fhem kopieren zu wollen. Funktionalität und vor allem Stabilität sind ja das Ziel. Lomgpoll ist eine Teilaufgabe, Stabilität vom Frontend ist die zweite. Beides sind ja, in Bezug auf pgm2, alte Hüte. Wenn da jetzt noch eine Lösung vom Himmel falle würde dann wäre ich glücklich und um einige Stunden Freizeit reicher  ;)

vg
jörg

das hmmm 'problem' ist das fast alle vorschläge und threads die sich hier um ein neues 'sexy' interface drehen am design fest gemacht sind :)

wie gesagt. ich glaube funktionalität und design bekommen wir mit dem fhem bordmitteln hin. und stabilität schaffen wir auch.

gruss
  andre

Hallo,
ich bin sozusagen "brandbeu" in diesem Forum, möchte aber trotzdem meinen Kommentar abgeben weil ich das Thema total spannend finde.
Bei mir im Haus läuft smarthome.py/smartvisu. Die Kombination ist schon ziemlich spannend. Aber FHEM finde ich auch sehr interessant.
Leider spricht mich das/die Frontend's nicht so richtig an, smartvisu könnte eine wirklich gute Erweiterung sein (und würde mir {und meiner besseren Hälfte;-)} den Umstieg schmackhaft machen.

Für smartvisu spricht der einfache Einstieg. Vorausgesetzt es gibt einen passenden Treiber wäre die Anpassung auf eigenen Bedürfnisse mit kleinen Kenntnissen wie man einen Editor betätigt leicht machbar.
HTML, PHP, Javascript, jscript etc -  Kenntnisse sind NICHT erforderlich. Bestehende Beispiele, die es ausführlcih gibt, sind leicht anpassbar und dadurch bekommt man schnell ein lauffähiges System.
(Mit den o.g. Kenntnissen kann man die Oberfläche natürlich noch viel feiner Anpassen.)

Ich denke, einen Treiber für smartvisu zu schreiben lohnt sich.
Leider kenn ich mich in FHEM noch gar nicht aus und weiss nicht wie groß der Aufwand ist. Meine native Annahme ist, das es möglich sein sollte. Gerne trage ich dazu bei. Z.B. beim Testen bzw. mit meinen (vielleicht kleinen) Kenntnissen über smartvisu.
Meine Annahme ist, dass man im Verzeichnis samrtvisu/driver eine neue Datei erstellt, als Muster dienen die anderen Treiber in diesem Verzeichnis. Thats all.

Gruss Jonah
 

Hi Jonah,

vielen Dank  :)

Wo findet man eigentlich den Editor ? Hast Du evtl screenshots (vom editor) ?

Ich versteh auch das knx System noch nicht so genau. Was ich aus der doku zu erkennen glaube ist das die Adressierung auf GADs basiert (?). Eine der Fragen für mich ist die Adressierung fürs Frontend. Irgendwie muss man ja eine Übereinstimmung zwischen den fhem device und dem was smartvisu erwartet bekommen. Da fehlt mir Verständnis. Ich habe gelesen das smartvisu von einigen als langsam beschrieben wird, hast Du Erfahrungen dazu ?


Danke  und Grüße
Jörg

ZitatWo findet man eigentlich den Editor ?

Sorry, da hast Du mich missverstanden.
Mit Editor meinte ich einen beliebigen Texteditor. Smartvisu hat von haus aus keinen eingebauten Editor.

Ich habe mir das Thema gestern auch angesehen und Domotiga beispielsweise geht den Weg ein eigenes Modul für Smartvisu zu haben dass einen Websockets-Server hat, der die Kommunikation macht.

Die Plots verwenden glaube ich RRD was natürlich toll von der Geschwindigkeit her ist und warum das RRD-Projekt in FHEM eingeschlafen ist weiß ich auch nicht.

Im Fall von FHEM wäre es vor allem wichtig einen performanten Weg zu finden zu Readings etc. zu kommen.

Telnet + Websockets hätte natürlich den Vorteil dass man die Bridge zu Smartvisu in einer beliebigen Sprache auch abseits von Perl schreiben könnte ;)

Zitatimport cherrypy
from ws4py.server.cherrypyserver import WebSocketPlugin, WebSocketTool

eine kurze frage wegen der plots: beim demo zugang bauen sich die plotz sehr sehr langsam auf. ich vermute fast das es absicht ist. kann man das auch ändern? meine fhem plots sind auch ohne rrd deutlich schneller als die plots dort.

die demo seiten sind bei mir noch an einigen anderen stellen sehr langsam und zäh. liegt das an dem server dort oder ist das bei einer lokalen installation auch so ?

gruss
  andre

Das würde mich auch interessieren, auf dem iPad1 und dem HP Touchpad die ich als Displays verwende war die GUI beinahe unbenützbar langsam, allerdings insg. nicht nur die Plots

Wobei ich das Konzept von Smartvisu sehr ansprechend finde, global Widgets zu definieren denen die zugrundeliegende Device eigentlich recht egal ist solange alles sauber gemappt wird. Das kommt meinen Vorstellungen einer hauptsächlich als Touch GUI verwendbaren Oberfläche bei der ich je nach Raum/Display auf einem Dashboard Widgets platziere sehr nahe.

Wobei natürlich auch FHEM Ansätze in diese Richtung hat, aber das Lösen des Widgets von der Device und die Platzierung auf einem Dashboard mit Grid sind noch sehr in den Anfängen ( wenn Floorplan ein Grid DND nachrüsten würde wäre schon mal ein großer Schritt gemacht denke ich) http://forum.fhem.de/index.php/topic,22491.0.html

ja. genau das konzept lässt sich aber auch mit fhem mitteln schon umsetzen.

ich bin gerade dabei das beispiel von weiter oben mit der heizungssteuerung beispielhaft umzusetzen. du gibst dann dem 'widget' die bis zu drei readings und das set commando das nötig ist und alles andere geht automatisch. das gleiche widget arbeitet dann mit max oder homematic oder fs20 heizungskomponenten. egal ob es ein wand thermostat für den ganzen raum oder ein heizungsthermostat für eine heizung ist. oder eine irgendwie selbst gestrickte heizungsteuerung mit dummys oder was auch immer. einzige voraussetzung ist das es readings für ist- und solltemperatur gibt und ein set für die soll temperatur. optional noch eine ventilstellung. egal in welchem device.

die syntax schaut etwa so aus:define myHeatingWidget rgHC <device>oder vollständigdefine myHeatingWidget rgHC actual=<device>:<reading> desired=<device>:<reading> valve=<device>:<reading> set=<device>:<set_command> ...wobei fast alles optional ist und aus defaults oder den vorher angegebenen werten abgeleitet wird.

das 'widget' kannst du dann in er raum übersicht, auf dem dashboard oder im floorplan verwenden.

das setzt genau diese möglichkeit die visualisierung und die steuerung logisch zu trennen um.

Gerade bei potentiell umfangreicheren Widgets wie zB einer Audio-Player Steuerung (Sonos/Squeezeserver/XBMC/MPD) wäre es sicher interessant die Darstellung zu vereinheitlichen und zu bündeln.

@Heizungssteuerung: Da kann ich zB gleich beitragen, dass bei mir je nach Raum von FHT8v über PID, MAX! Stellantrieb und eine Structure die ein PID+Threshold bündelt und über ein Dummy gesteuert wird, von den Boost Dummys mal abgesehen ;) - (ahja, 3 verschiedenen Sorten von Temperatur/Feuchte-Erfassung hätte ich noch zu bieten) + ein watchdog dass über den Taupunkt die Heizung unter den großen Dachflächenfenstern bei Bedarf hochfährt

na das wäre ja der perfekte test um zu sehen ob es wirklich so device unabhäng ist wie ich es mir vorstelle :)

@justme

wäre es für die lesbarkeit beim define nicht besser die einzelnen mappings in attribute auszulagern statt alle im define zu haben (nicht zuletzt für die lesbarkeit)

das ist eine gute frage...

ich mag es wenn ich das device auf einen schlag anlegen kann. beim anlegen oder beim ändern jedes attribut einzeln durchzugehen finde ich unhandlich.

meine richtlinie ist immer: ins define kommt was nötig ist damit es im normalfall sinnvoll funktioniert. in attribute kommen dinge die das verhalten beeinflussen. manches kann man sicher so oder so sehen.

mit der = syntax ist es im define aber möglich völlig unabhängig von der reihenfolge zu sein. wenn man das ein paar mal gemacht hat ist es sehr praktisch.

Da geb ich dir recht, außerdem kann man das define ja immer nachträglich bearbeiten.

Andererseits denke ich zB an das theoretische Audio-Player Widget, wo es dann vielleicht unübersichtlich werden kann.

Und dann hätten wir da natürlich noch das Homie-Frontend, wobei was ich so mitgelesen habe hier ja auch nicht wirklich eine strikte Trennung in Widgets vorhanden ist.

Ich glaube ich sollte mal die Kategorie Frontends durchsehen und zusammenschreiben, wer an was arbeitet ;)

@justme, man könnte allerdings sagen, dass der thread derzeit streng genommen gehighjacked ist.

Den Weg über Set / get zu gehen halte ich für grundsätzlich falsch weil er

A: eine sofortige Abhängigkeit von konkreter fhem implementation schafft. Beispiel, das RGB Widget von fhem

B: eine Echtzeit Aktualisierung auf dem Frontend muss strukturiert werden, am jetzigen longpoll vorbei

C: Set und get dürfen nicht über fhemweb laufen.

Es macht doch keinen Sinn eine Kopie der aktuell verwendeten (Bezug Frontend) Umsetzung mit anderem Design zu schaffen, da erbt man doch die ganzen Probleme mit.

Vg
Jörg

ja. die posts vorhin waren zum teil off topic. aber eben nur zum teil :). ich werde das was nicht andere frontends betrifft in diesem thread: http://forum.fhem.de/index.php/topic,27353.0.html (http://forum.fhem.de/index.php/topic,27353.0.html) halten.

aber zurück zu smartvisu (oder einem anderen reinen frontend):

ich mag immer noch nicht glauben das longpoll irreparabel kaputt ist. auch wenn es nicht 1:1 übernommen wird wäre es schön wenn eine 'reparierte' longpoll anbindung unter welchem namen auch immer wieder in fhemweb einfliessen würde.

longpoll ist ist nicht unbedingt nur das was zur aktualisierung in fhemweb verwendet wird sondern auch der mechanismus der die daten für den event monitor und das inform kommando liefert. je nach frontend ist es ja durchaus sinnvoll nur die events die im aktuellen raum eine rolle spielen zu bekommen. das gibt es hier ja schon.

der rückweg sollte natürlich nicht über fhemweb sondern telnet oder irgend ein anderes socket das näher am kernel ist laufen.

Ich hatte ja begonnen einen Dashboard Multimedia Tab zu erstellen, mithilfe von einigen Dummys und rGs kann man da schon einiges machen...
Ich schrieb auch ein bisschen Howto mässig mit und bastelte an einer 99_myAudioUtils.pm
Aktuell rutscht mir aber ein anderes, wichtigeres Projekt dazwischen - ich werds wohl an den Nagel hängen müssen.

Falls jemand weiter basteln möchte versorge ich Ihn gerne mit dem bereits stehendem Grundgerüst / Konzept.

Zitatich mag immer noch nicht glauben das longpoll irreparabel kaputt ist. auch wenn es nicht 1:1 übernommen wird wäre es schön wenn eine 'reparierte' longpoll anbindung unter welchem namen auch immer wieder in fhemweb einfliessen würde.

Longpoll fußt auf fhemweb und das ist in Bezug auf Stabilität, Performance etc Dauerausstellung. Ich kann die ganzen workarounds schon garnicht mehr zählen.

Das ist jetzt nicht despektierlich gemeint, aber genau da schreist doch nach alternativen

Vg
Jörg

ich sehe longpoll nicht fest mit fhemweb verheiratet sondern aus mehreren teilen bestehend:

1. den mechanismuss events zu sammeln und die für einen raum unwichtigen weg zu schmeissen bzw. nur bestimmte zu abonnieren
2. das socket auf dem die events raus geschickt werden
3. die verarbeitung durch js code

1. ist nicht fhemweb spezifisch
2. eigentlich auch nicht
3. ist nicht fhemweb spezifisch sondern *ist* fhemweb

1. + 2. ohne blocking probleme + neues frontend wäre z.b. die smart visu anbindung
1. + 2. ohne blocking probleme + 3. wäre ein 'besseres' fhermweb

neben den blocking problemen in 2. wäre es noch schön wenn die codierung der nachrichten verbessert wird.

aber vielleicht reden wir auch aneinander vorbei wenn du von alternativen sprichst.

gruss
  andre

longpoll wird ganz konkret in 01_FHEMWEB beantwortet, mit ganz konkret den gleichen Mechanismen die fhemweb als frontend ausliefern.

Die performance / Zuverlässigkeit wäre also genau mit dem Teil verknüpft wo es aktuell "hängt". Das macht schon daher keinen Sinn. Dazu kommen "Folgekosten" wie

* wenn Rudi irgendwas am longpoll ändert, funktionieren Aufsätze nicht mehr. In der Vergangenheit so geschehen mit floorplan, webview.
* Das Konzept der Räume (-> longpoll) ist eine fhem Konzept, kein smartVisu Konzept.
* Eine Kommunikation die auf fhemweb get/set aufsetzt setzt sofort voraus das port 8080 (oder Vergleichbar) offen ist.
* Benutzer und Rechte können dann (wieder) nur von fhemweb erbracht werden.
* Die smartVisu widgets erwarten GAD Adressen. Die Umsetzung auf fhem device muss clientseitig erbracht werden.

Wenn Du Dir die smartVisu treiber anschaust siehst Du verschiedene Konzepte die dort umgesetzt werden, beispielsweise eine Websocket Implementierung. Im Augenblick ist genau das, mit einem passenden fhem device als counterpart mein Favorit.

Bevor ich das schreibe (im Kern ja überschaubarer Aufwand) würde ich gern noch mehr in Bezug auf smartVisu verstehen und auch ein Konzept haben wie eine zukünftige user/device/rechte Verwaltung dafür funktionieren könnte. Das sollte in dem fhem device zumindest in der Architektur bereits angelegt sein.

vg
jörg

ZitatFür die meisten Bastler würde es schon reichen wenn sie ein Werkzeug an die Hand bekommen mit dem sie
eine Oberfläche bekommen das auch den "Hausfrauen"-Test besteht - und das bei aller liebe, und nein, da braucht sich jetzt keine Dame
im Forum angegriffen fühlen,  aber PGM1-X sind hier bei den meisten Leuten gnadenlos durchgefallen. Sprich hier reicht es schon wenn man
quasi ein Frontend fürs Frontend bekommt - und ja - mir fehlt hier definitiv noch eine Menge technisches Wissen der FHEM internas.

Hi,

ich hab das jetzt so verstanden das Du fhemweb erweitern möchtest. Mach das, das ist aber nicht Thema dieses threats  ;) Es geht auch nicht darum fhemweb irgendwie generell zu ersetzen sondern um die Möglichkeit auch (!) smartVisu verwendet zu können. Wer möchte kann, keiner muss  ;)

vg
jörg

@herrmannj: longpoll setzt auf den inform mechanismus auf. und der ist nicht fhemweb spezifisch sondern geht z.b. auch per telnet. diese inform daten auf ein socket/websocket zu schieben und zwar nicht smartvisu spezifisch sondern so generell das auch andere frontends (und irgendwann auch fhemweb) daran hängen können ist die idee. ob man das raum konzept dann nutzt oder sozusagen (implizit) den raum everything aboniert wäre dann frontend abhängig.

fhemweb get/set über port 8080 habe ich nie gemeint.

werden die gad Adressen wirklich auf ein komplettes device gemapped? ich dachte noch feinkörniger auf ein device:reading bzw. device:kommando.

@h0ly0ne: ich glaube über die db zu gehen ist der falsche ansatz. und selbst wenn du über die db gehst sollte es nicht über fhemweb sein...

gruss
  andre

ah, verstehe. Sehe ich dann ähnlich.  :)

Der genaue Transportweg ist ja auch schon sekundär. Das mit den GAD hab ich noch nicht komplett verstanden (Wenn sich jemand zu einem crashkurs berufen fühlt, sehr gerne  8) ). Device/reading würde auch Sinn machen, irgendwo muss es ja ein mapping geben.

Beispiel RGB LED, da geht ja von white (kelvin) über nur RGB bis HSV alles und das muss ja

a: in den Möglichkeiten die das widget bietet (bieten kann) und dem was
b: die lampe bietet

irgendwo ge-matched werden. Bzw im Idealfall erfährt das widget was die lampe kann und stellt seine visu darauf ein. Bei HVAC, Securiity selbst Wecker siehts ja auch so aus.

Wichtig ist ja das die Umsetzung dann auf fhem Seiten und auf der visu Seite die Kompatibilität beibehält, sonst wird das nicht angenommen werden.

vg
jörg

ja. genau. aber nicht nur kann es widgets für unterschiedlich aspekte eines device geben wie in deinem beispiel sondern es können auch unterschiedliche (oder gleiche) aspekte aus mehreren devices in einem widget kombiniert werden. siehe z.b. heizungssteuerung mit ist- und soll temperatur aus unterschiedlichen sensoren.

Zitat von: justme1968 am 01 Oktober 2014, 19:00:20
ja. genau. aber nicht nur kann es widgets für unterschiedlich aspekte eines device geben wie in deinem beispiel sondern es können auch unterschiedliche (oder gleiche) aspekte aus mehreren devices in einem widget kombiniert werden. siehe z.b. heizungssteuerung mit ist- und soll temperatur aus unterschiedlichen sensoren.

yepp, genau. :D Dann macht eigentlich nur GAD == reading Sinn

Nun müsste man halt erst einmal verstehen ob es Regeln für die GAD gibt die man einhalten muss (bzw sollte, siehe Kompatibiltät), ob es Regeln für Formate bzw Einheiten gibt. Danach könnte das mapping im fhem-treiber-device (so ala Floorplan editor) gemacht werden oder in end device (bsp FHT) als attr liegen.

Ersteres würde ich eigentlich bevorzugen weil es ja die Möglichkeit eröffnen würde von dort aus ein Layout in Richtung smartVisu zu exportieren.

Zusätzlich hätte ich gerne noch einen Plan bzgl user/device etc. Bei der Variante 1 könnte man Regeln im Editor anpassen das wäre eigentlich ganz charmant. (Also: Eltern können Alarmanlage scharfschalten, Kind nicht. Wohnzimmer Tablett steuert Heizung alle, Kinderzimmer nur Kind, Eltern können überschreiben. Mobiler zugrif kann x ... usw)

Dafür müsste man auf Treiber Seite erkennen wer / womit zugreift .

vg
jörg
     

je mehr ich darüber nachdenke umso mehr sehe ich die Editor Variante:

Im Idealfall lädt fhem die Liste der verwendeten widgets aus der visu (ich meine da eine cfg gesehen zu haben, bin mir nicht sicher).

Ausgehend davon kann man dann in fhem via fw_detail-Editor den verwendeten GADs (der widgets) das entspechende fhem reading (get, etc) zuordnen. Kombiniert mit regex oder Makro-Definition würde das auch gleich das Problem der vielen individuellen fhem device lösen. Der "Übersetzer" für "was auch immer" wäre dann universell. Rückwärts (set) genauso.

Wie man das mit logs macht müsste ich noch prüfen. Im Idealfall soviel Infos wie möglich aus den gplot.

Na, ich denke das kann was werden.  :)

Ergänzungen ?

vg
jörg

das klingt nicht schlecht.

Ola an alle smartVisu Interessenten,

kurze Wasserstandsmeldung:

bzgl Driver und Websockets habe ich keine Showstopper gefunden, erste kleine Test positiv.

Zur Autorisierung:
mir erscheinen Zertifikate (X509) hier als geeignetes Mittel.

Das würde dann in etwa so ablaufen:
die display device (zb ipad) benötigen ein selbst erzeugtes Zertifikat.
smartVisu (lamp + smartvisu) prüfen das Zertifikat und liefern die visu für dieses device aus.
fhem prüft das zertifikat (auf websocket), ordnet sie einem device zu und nimmt nur whitelist Befehle dazu an, respektive schickt readings dazu weg (wenn verbunden).

Innerhalb fhem wird jedes device (iphone gg, iphone wuki, tablet wohnzimmer ...) als eigenes device angelegt. Dann sind user und device miteinander verknüpft. Iphone wuki bekommt nur wecker wuki usw.

Das löst noch nicht das Problem zb des Tablett im Flur über das sich zB die Alarmanlage ausschalten lässt. (GG darf, Einbrecher lieber nicht  ;) ). Das liese sich aber zb so lösen das ein smartVisu keypad widget erstellt wird. Widget sendet pin an fhem, fhem prüft und gibt spezielle settings, (Alarm) für xx minuten frei. Prüfung dafür findet in fhem statt, logischerweise nicht im client.

Hat jemand Vorschläge/Einwände/Hinweise zu diesem Konzept ?
Passt soweit für alle ?

vg
Jörg

Hi @all,

kurze Info:
das Projekt läuft soweit, ich denke im Lauf der kommenden Woche eine alpha hier rein stellen zu können (bin im Augenblick short-of-time).

Hatte auch einen netten Kontakt zu Martin vom smartVisu team. Die Hoffnung das er mir noch mehr Doku zur Verfügung stellt hat sich zwar nicht erfüllt - darüber hinaus sehr hilfsbereit.

Wer also möchte kann durchaus schon ein wenig mit smartVisu "spielen" -> also üben wie man eigene Seiten gestaltet, aufbaut. Krönung wäre wenn jemand ergründet wie man eigene widgets schreibt. (smartVisu.de)

Die final wird pro device ein eigenes Unterverzeichnis benutzen. Dazu kommt in die index.php eine Weiche. Eine Anleitung zum installieren der Zertifikate werde ich für nginx erstellen.

vg
Jörg

Hi @herrmannj

Ich melde mich jetzt auch mal wieder zu Wort.
Deine Idee mit den Zertifikaten halte ich für sehr gut. Aber wenn du z.B auf einem iPad das mit einem Zertifikat löst, geht das doch wahrscheinlich nur mit einem gejailbreakten, oder liege ich da falsch, kann man bei iOS ohne Jailbreak ein Zertifikat erstellen? (vll. wie wäre es, wenn man die Deviceerkennung über die Mac-Adresse macht? Oder wäre das zu unsicher?).

Was für eine Doku brauchst du denn?
Die für die man einen Zugang braucht? Weil eine "Leseprobe" gibt es ja auch. Wenn ich es richtig verstanden habe, hast du auch schon einen Teil bekommen, oder liege ich falsch?

Ich finde es jedenfalls sehr toll, das du einen Treiber schreibst.
Wenn ich irgendwie helfen kann, stehe ich gerne zur Verfügung. Meine Programmierkentnisse beschränken sich zwar auf C, HTML und PHP da ich nur in der Freizeit mit programmieren zu tun habe und Elektroniker in Ausbildung bin.

mfg,
Tropaion

Hi herrmannj,

finde Klasse was du da machst. Wenn du Mithelfer brauchst kannst gerne nen Aufruf machen.

Gruß jody

Hi,

Mitstreiter: na klar! gerne.  :) Das "besondere" an smartVisu ist ja das es ein offenes System ist was es schon gibt. Wer möchte kann sich auf smartVisu.de zB ein komplettes Image für den raspi runter laden. Einfach auf sd reicht schon aus um Trockenübungen zu machen. Da ist dann zwar noch keine fhem Anbindung drin, aber es funktioniert gut genug um zu lernen oder zu testen.

So hab ich das auch gemacht, das reicht mir im Augenblick auch völlig aus um den Treiber und die Einbindung zu schreiben. Darüber "wie" man dann smartVisu Seiten an sich erstellt kann ich noch gar nicht viel sagen - da ist Forschungs- und Dokumentationsbedarf.  :)

Zu den Zertifikaten: ob der Plan die Praxis übersteht muss sich noch zeigen. Das sollte aber (so recherchiert) auf allen major Plattformen problemlos gehen, 'türlich auch ohne jailbreak.

Mac oder IP währen für die ersten Tests eine Alternative, beides lässt sich aber leicht fälschen und ist per se unsicher. Zertifikate hätte ich (wenn ich das eh von Grund auf mache) drin. Gleiches gilt für eine "innere" Sicherheit in Bezug auf "wer-darf-was", also nichts aufgesetztes sondern gleich in core verankert, das kommt mMn oft zu kurz. Dabei ist "meine Wohnung" für mich echt "sicherheitsrelevant".

Ist zwar komplizierter das so zu coden, (dauert länger). Denke aber das wird sich auszahlen.

vg
Jörg

Hi,

wenn ich es recht verstehe ist das dann Deviceübergreifen, oder?
Das heißt man braucht nicht für jede Device einen "Treiber".

Die "Trockenübungen" hätte ich sowieso gemacht, und ich denke nicht das sonderlich schwer wird. Und wenn doch, hab ich (wie schon erwähnt) deinen Bekannten der die SmartVisu im Einsatz hat, denn kann ich Notfalls auch fragen.

Meine wirkliche Frage war, ob du Hilfe benötgst (sofern ich dir helfen kann)?
Ich werde jetzt mal eine Anfrage stellen um die Doku zu bekommen.

mfg,
tropaion

Hi,

Genau. Damit es keine Verwirrungen gibt, smartvisu bekommt meinen Treiber für fhem und fhem bekommt ein Modul für smartvisu.

Dann wird schon das individuelle device (mein iphone, mein Tablett, das Tablett im Wohnzimmer, der Wecker...) einzeln angelegt. Bedeutet ja aber nicht das man dann immer bei Null startet. Man wird ein bestehendes device kopieren und anpassen.

Habe übrigens gestern nach deiner Frage nochmal gegoogelt, scheint so das ausgerechnet meine geliebte webviewcontrol keine Zertifikate kann, der Android Browser ab 4 kann es. Wird also auf beide Varianten rauslaufen, intern ip, wo geht Zertifikate.

Danke nochmal für das Hilfsangebot. Bei der direkten Einbindung fhem kannst du im Augenblick nicht viel tun. Da du PHP, js etc kannst könntest du aber tatsächlich innerhalb smartvisu viel machen. Um beispielsweise die webviewcontrol einzubinden wäre es wichtig ein passendes widget zu entwickeln.

Gilt auch für die Alarmanlagen Funktion. Beispiel, im Flur hängt dein Tablett, smartvisu läuft, licht, Heizung lassen sich einstellen. Alarmanlage kann aktiviert und deaktiviert werden. Damit jetzt nicht ein Einbrecher an dem Tablett die Alarmanlage deaktiviert wäre es sinnvoll wenn er dazu einen Pin eingeben muss und die Funktion dann auf dem Server freigegeben wird.

Da sehe ich super Ansätze um arbeitsteilig zu arbeiten, jede Hilfe ist wirklich sehr willkommen. Wobei das schon über Hilfe rausgeht, mit dem Thema Treiber und Anbindung bin ich erstmal ausgelastet. Der Teil smartvisu an sich ist noch komplett zu haben  ;)

Vg
Jörg

Hi,
wie wäre es denn wenn du das bei der Webviewcontroll über die App-ID machst? Zu dem ist die ja meines erachtens gedacht. Und diese ist auch frei einstellbar. Ich würde ja eig gerne mein altes iPad verwenden, weist du schon was, ob das mit denn Zertifikaten geht? Jailbreaken würde mich auch nicht stören.

Wegen dem Widget. Ich "kann" C, PHP & HTML, JS kann ich leider nicht, wäre aber mal interessant da reinzuschauen.
Meine PHP-Kenntnisse reichen für so ein Programm: http://www.yakuzasubs.at/Subtitle-Translator.php

Ich habe jedoch keine scheu mich in der Freizeit damit stärker zu beschäftigen.

mfg,
tropaion

Soweit sind wir noch nicht. Auch wenn Zertifikate nicht funktionieren werde ich für eine Lösung sorgen, Zertifikate werden sicherer sein.

Ipad: hängt vom ipad ab wegen Geschwindigkeit. Bei mir: altes iPhone 3GS sehr langsam, macht kein Spaß. Ipad2 geht gut. 4s, dito.

Webviewcontrol: besteht aus zwei Teilen. Die app, wird auf Android installiert und stellt den Rahmen. Die Inhalte (eben auch Funktion, mach Display an, spiele Lied ...) kommen von fhem. Wenn smartvisu das liefert braucht es ein Widget um die Funktionalität dort abzubilden.

Vg
Jörg

Hi,
wenn ich das richtig verstanden habe, braucht man für SmartVisu also ein Widget das die Inhalte im richtigen Format an den "Rahmen" übergibt.
Wie funktioniert denn die Inhaltsübertragung? Ist das wie ein Browser aufgebaut, das einfach ein mit PHP erzeugtes HTML-Dokument anzeigt?

mfg,
tropaion

Nein, lade und installiere smartvisu mal.

Alles browser basiert. Widgets reichern das um spezielle Funktionalität an. Browserseitig. Javascript. Gesteuert von fhem.

Das webviewcontrol von Dirk stellt einen zusätzlichen Browser auf Android zur Verfügung der gleichzeitig auch Hardware steuern kann. (Display, Sound, ... Auf dem Android)

Wenn also smartvisu im webviewcontrol läuft läuft es in einem Browser mit spezieller Funktionalität.

Vg
Jörg

Ok, dann habe ich es eh richtig verstanden.
Warscheinlich nur schlecht beschrieben/formuliert.
Ich werde heute Abend mal eine Testoberfläche einrichten mit XAMPP und mir das mal anschauen.

mfg,
tropaion

Zitat von: Tropaion am 08 Oktober 2014, 14:44:23
Ok, dann habe ich es eh richtig verstanden.
Warscheinlich nur schlecht beschrieben/formuliert.
Ich werde heute Abend mal eine Testoberfläche einrichten mit XAMPP und mir das mal anschauen.

mfg,
tropaion

Vermutlich (sorry). Nun passt es ja. Im Prinzip geht es also wirklich darum smartvisu an die speziellen Anforderungen der eigenen Installation anzupassen, bzw. eben um die Dinge (Widgets) zu erweitern die speziell für fhem sinnvoll sind.

Viele Sachen kann es ja schon von Haus aus. Vielleicht ja eine gute Chance in js plus jQuery einzusteigen - wer mag. Bedarf besteht  :)

Vg
Jörg

Leider bin ich gerade bei den Strukturen von FHEM viel zu unbewandert um das sauber abbilden zu können, aber was ich bei der openhab integration in smartvisu gesehen habe ist der Aufbau immer, dass es einen Treiber gibt, der aber nur die Endpunkt-Infos zum jeweiligen System bereitstellt. Die eigentliche Logik ist dann in Modulen in den darunterliegenden Heim-Automatisierungs-Servern wie FHEM. Standard-Weg scheint für die Kommunikation derzeit Websocket zu sein oder?

Prinzipiell wäre es sogar denkbar die SmartVisu abseits von Perl zu integrieren zB mit Python eine Telnet-Verbindung aufbauen und dann einen Websockets-Server für smartvisu ;)

Prinzipiell bin ich der Meinung (v.a. nach den ganzen Diskussionen zu Homie, YAF, Dashboard etc.) dass das Web-Interface und damit der Familien/Breiten-Akzeptanz-Faktor das größte Manko von FHEM sind. (die vielzahl der unterstützten Systeme im Gegenzug der Vorteil)

Wenn wir hier die verstreuten Anstrengungen für fast jedes Modul ähnliche Elemente neu zu bauen (XBMC/MPD/Sonos/Squeezeserver oder die LED-Strip-Sachen) eher darin investieren, dass es ein wirklich gutes SmartVisu Widget und eine performante Einbindung in FHEM existiert ist allen geholfen.

Ja genau. Die Anbindung realisiere ich über websockets, als eigenes Modul. Das

Zitat von: drdownload am 08 Oktober 2014, 15:37:10
Wenn wir hier die verstreuten Anstrengungen für fast jedes Modul ähnliche Elemente neu zu bauen (XBMC/MPD/Sonos/Squeezeserver oder die LED-Strip-Sachen) eher darin investieren, dass es ein wirklich gutes SmartVisu Widget ... existiert ist allen geholfen.

So sehe ich das auch. Genau darum kümmere ich mich aktuell jedoch nicht (hab ja mit dem Treiber genug zu tun). Wir haben ja hier oft user hier im Forum die sagen das sie gerne mitmachen würden aber nur PHP, HTML und js können. Genau das ist jetzt auch gefragt  ;)

Vg
Jörg

Kann SmartVisu eigentlich mit mqtt reden? Dann könntet Ihr einfach das neue MQTT-modul (http://forum.fhem.de/index.php/topic,27532.0.html) zur Anbindung an fhem benutzten. Das habe im Prinzip genau für solche Dinge geschrieben.

Gruß,

Norbert

vielen Dank. Ab Werk spricht meines Wissens nach smartVisu kein mqtt. Der Transportweg selber ist aber auch nicht so wild (vermutlich kann man smartVisu das beibringen).

Ein Websocketserver aufzusetzen war aber auch nicht wirklich schwer. Da ganze "rundherum" würde man auch bei mqtt aufsetzen müssen (zumindest wenn so wie von mir gewünscht  ;) ) Das betrifft zum einen die Mandantenfähigkeit (end-device werden seperat betrachtet und beschickt). Außerdem müssen die fhem states / readings in Formate umgesetzt werden die smartVisu versteht und erwartet. Besonderheiten zB für farbige LED, da werden die 3 RGB Werte getrennt gesendet, solche Sachen halt.

Das subscribe/publish haben die ähnlich umgesetzt, smartVisu fragt die subscription an und das fhem Modul soll das tracken und bedienen.

Den Websocketserver habe ich bei der Gelegenheit gleich forken lassen damit er etwas vom fhem Prozess entkoppelt ist, das ganze rundherum macht ja immer die Arbeit wenns was werden soll ...  8)

vg
Jörg

Hallo herrmannj,
wie läuft es denn?
Gibt es Neuigkeiten, wie läuft es mit denn Zertifikaten?
Lg,
Tropaion

Hi,

Wenn nicht was unvorhergesehenes passiert schaffen wir die für diese Woche geplante alpha.

Stand ist, websocket Server läuft, ist vom fhem Hauptprozessor entkoppelt und kann mit ihm kommunizieren. Nachrichten von smartVisu kommen an, Protokoll für einzelne items ist verstanden (Plots und Dialoge kommen später)

Zertifikate stehen auch noch zurück, die alpha wird die device an den ip Adressen unterscheiden.

Am device Modul arbeite ich, dort aktuell am Editor um die die fhem Reading / Events in die smartvisu Gad zu übersetzen. Das mit den Gad war übrigens viel weniger komplex als ich dachte. In der Definition von smartvisu ist das einfach freitext.

Vg
Jörg

Hi,
das heißt ich muss meinen Geräten eine fixe internet IP zuweisen oder?
Weil mein Router weist den Geräten bei jeder neuen Einwahl eine andere IP zu.
Und von außen geht das eig. gar nicht, weil das Handy ja auch immer einen neue IP bekommt.
Wäre es nicht sinnvoller das über die MAC zu machen?
Lg,
Tropaion

Immer langsam  ;)

Die erste Version ist eine alpha weil ganz vieles noch garnicht drin ist und das was drin ist darf noch ganz viel wachsen. Das ist nicht als produktiv geplant sondern zum testen und Erfahrung sammeln.

Zertifikate kommen dann später dazu (und ersetzen/ergänzen die ip Bindung). Um das Modul ins Netz zuhängen ist das es noch viel zu früh.

Vg
Jörg

Hallo! Bin auch interessiert an einem smarten und reaktiven Frontend! Wird es ein Github Projekt geben? Würde mich dann auch gern beteiligen... Gruß, Bernd


Sent from my iPhone using Tapatalk

Keine Sorge, ich will dir mit denn Fragen keinen Druck machen^^
Nur wenn ich über etwas rede (im technischen Bereich) möchte ich auch immer die Funktion und den Hintergrund dazu wissen.
Weil wenn ich mich mit etwas beschäftige möchte ich immer genau wissen wie es funktioniert.
Ich weiß schon was ne Alpha ist und mir ist natürlich auch klar das das nur zum testen ist ;)

@bgewehr
Wenn ich herrmannj richtig verstanden habe, will er das schon als GitHub-Projekt veröffentlichen.

Mfg,
Tropaion

Zitat von: Tropaion am 13 Oktober 2014, 15:17:12
Keine Sorge, ich will dir mit denn Fragen keinen Druck machen^^
Nur wenn ich über etwas rede (im technischen Bereich) möchte ich auch immer die Funktion und den Hintergrund dazu wissen.
Weil wenn ich mich mit etwas beschäftige möchte ich immer genau wissen wie es funktioniert.
Ich weiß schon was ne Alpha ist und mir ist natürlich auch klar das das nur zum testen ist ;)

@bgewehr
Wenn ich herrmannj richtig verstanden habe, will er das schon als GitHub-Projekt veröffentlichen.

Mfg,
Tropaion

Ah, super. Dann passt das ja.

@bernd,
Was würdest du denn machen wollen, also zB PHP, js im Frontend ?
Vg
Jörg

Hallo, Jörg, ich bin leider kein erfahrener Entwickler in irgendwas. Meine Beiträge können aber Test, Ideen und kleinere Optimierungen sein. Dies habe ich mehrfach erfolgreich in anderen Projekten betrieben. Mal sehen, wie ich helfen kann! Ich stelle fhem derzeit von Fritz!Box auf Banana Pi / SSD mit RaspBian um. Dabei möchte ich auch die SmartVisu einsetzen. Lass uns sehen, welche PRs ich zustande bekomme. Freu mich drauf! Gruß Bernd


Sent from my iPhone using Tapatalk

Ja, super. So wächst man ja dann ja rein. Das smartVisu gibt es ja bereits, Du könntest es Dir unter smartVisu.de runterladen und auch schon auf dem Banana installieren. Es braucht einen webserver mit php (zb nginx). Dann kannst Du durchaus schon Erfahrungen sammeln, beispielsweise in der Installation und wie man Seiten erstellt. Neben der reinen Programmierung dafür geht es aus user Sicht darum wie man Seiten erstellt etc.

Ganz wichtig wäre es auch das zu dokumentieren, in Kürze auch vielleicht auch im Wiki ?

Für smartVisu fliegen im Netz in diversen Foren kleinere und größere tips rum, howtows, teilweise auch widgets. Bei denen (smartVisu) ist es aber genauso wie bei uns, Doku steht halt nicht gaaanz oben  ;) Da ein wenig zu suchen, zu finden und Infos zusammen zu stellen fehlt mir die Zeit, dabei ist das ganz wichtig.

Wenn dann in Kürze die fhem Einbindung kommt hast Du schon einen soliden Vorsprung.

vielen Dank
vg
Jörg

Prima! Doku und Wiki kann ich gut!


Sent from my iPhone using Tapatalk

Also wenn es um Doku geht, kann ich theoretisch auch eine schreiben.
Zwar nicht wie man die SmartVisu installiert am Raspi oder anderem Gerät (Ich weis wie es geht, aber ich weis zu wenig über die unterschiedlichen Geräte), jedoch kann ich eine schreiben, wie man Seiten erstellt, usw. ... .

Hallo Zusammen,

der Ansatz über smartvisu finde ich super, das ganze hatte ich mir auch schon mal angesehen. Mir war nur die Schnittstelle nicht klar geworden und perl ist nicht ganz mein Ding. Toll dass daran nun aktiv gearbeitet wird.
Ich hatte mir für meinen Teil gedacht, warum immer das Rad neu erfinden und hatte hierbei die Oberfläche von smartvisu entdeckt. Es wäre schön, wenn die etwas angestaubte fhem-weboberfläche mal aufpoliert würde.
Wenn nun die Schnittstelle zwischen fhem und smartvisu funktioniert wäre das toll, denn dann kann ggf. Fhem und smartvisu unabhängig voneinander weiterentwickelt werden.

Bin auf die ersten Testversionen sehr gespannt und werde das auch ausgiebig testen, sofern dieses hier weiter entwickelt und -vor allem- auch veröffentlicht wird.
Leider ist das ja bei Beispielsweise meinem bisherigen Hoffnungsträger "Hoanoho" nicht mehr zu erwarten.....

Gruß
Kai

Hi,  kann man eigentlich dann Smartvisu auf einem Rpi laufen lassen und auf einem anderen Fhem oder sollen die beide auf dem gleichen laufen?

Mal grundsätzlich gefragt: ist die gewählte Technologie nicht ebenso geeignet, um OpenHab an FHEM anzubinden? Da ist ja prinzipiell noch einiges möglich...


Sent from my iPhone using Tapatalk

Zitat von: Tropaion am 13 Oktober 2014, 17:57:37
Also wenn es um Doku geht, kann ich theoretisch auch eine schreiben.
Zwar nicht wie man die SmartVisu installiert am Raspi oder anderem Gerät (Ich weis wie es geht, aber ich weis zu wenig über die unterschiedlichen Geräte), jedoch kann ich eine schreiben, wie man Seiten erstellt, usw. ... .

ja Seiten erstellen wäre sehr hilfreich. Vielleicht ja ebenfalls wiki ?

vg
jörg

Zitat von: hyper2910 am 13 Oktober 2014, 18:50:09
Hi,  kann man eigentlich dann Smartvisu auf einem Rpi laufen lassen und auf einem anderen Fhem oder sollen die beide auf dem gleichen laufen?

Wie das am Ende aussieht ist noch nicht sicher, Stand jetzt geht es auf zwei unterschiedliche Systeme.

vg
jörg

Super, das finde ich gut, dann setze ich schon mal einen zweiten rpi mit Smartvisu auf.

Ich würde eine Installation von FHEM und SmartVisu auf einem einzigen System bevorzugen. Sonst wird mir mein Zoo hier zu groß... Ist das im Moment ausgeschlossen, oder kann man das mit ein paar zusätzlichen IP-Ports ausgleichen?


Sent from my iPhone using Tapatalk

Zitat von: bgewehr am 13 Oktober 2014, 19:04:10
Mal grundsätzlich gefragt: ist die gewählte Technologie nicht ebenso geeignet, um OpenHab an FHEM anzubinden? Da ist ja prinzipiell noch einiges möglich...


Sent from my iPhone using Tapatalk

offene Antwort: keene Ahnung  :) In der Hauptsache auch deshalb schon nicht weil ich das Protokoll von openHap nicht kenne. Aber lass es uns locker angehen, smartVisu ist erst mal genug Arbeit ...  :)

vg
jörg

Also später vielleicht...


Sent from my iPhone using Tapatalk

Zitat von: bgewehr am 13 Oktober 2014, 20:51:54
Ich würde eine Installation von FHEM und SmartVisu auf einem einzigen System bevorzugen. Sonst wird mir mein Zoo hier zu groß... Ist das im Moment ausgeschlossen, oder kann man das mit ein paar zusätzlichen IP-Ports ausgleichen?

doch, doch, das sollte gehen (ich habs noch nicht probiert, aber alles spricht dafür).
Für fhem bleibt alles beim alten, 3 neue Ports kommen über den smartVist treiber dazu und smartVisu läuft auf einem webserver (80 und 443).

für ein produktiv System würde ich dann etwas schnelleres nehmen.

vg
jörg

Hallo herrmannj,
mit "Seiten" meinte ich eh eig Wiki, also Wikiseiten.
Hast du das als Webseite interpretiert?
Einfache Webseiten kann ich natürlich auch machen, hattest du da leicht etwas in aussicht?
Lg,
Fabian Plaimauer

Zitat von: Tropaion am 13 Oktober 2014, 21:25:48
Hallo herrmannj,
mit "Seiten" meinte ich eh eig Wiki, also Wikiseiten.
Hast du das als Webseite interpretiert?
Einfache Webseiten kann ich natürlich auch machen, hattest du da leicht etwas in aussicht?
Lg,
Fabian Plaimauer

Hi Fabian,

ja, ich hatte das anders interpretiert: wiki Seiten mit dem Inhalt "wie erstelle ich smartVisu Seiten "   ;)
Sonst hab ichs nicht verstanden  :)

vg
jörg

Zitatja, ich hatte das anders interpretiert: wiki Seiten mit dem Inhalt "wie erstelle ich smartVisu Seiten "

Genau das meinte ich ;)

Smartvisu.de ist down? Setzen wir hier auf das falsche Pferd?


Sent from my iPhone using Tapatalk

Die Seite ist nicht down, nur vorübergehend gesperrt.

wehe !  :)

Immer noch offline... Das macht aber keinen so guten Eindruck! Oder sind gestern die Löwen eingestiegen?


Sent from my iPhone using Tapatalk

alles wieder gut. who knows ...

Hi,

Habe Smartvisu mal installiert,  wie hier beschrieben
https://github.com/mknx/smarthome/wiki/Komplettanleitung-Installation-sh.py-,-smartVISU,-eibd-und-1-Wire

Jedoch komme ich nicht mehr auf die Controller Seite,  das ist nur beim ersten mal möglich gewesen.  Hat jemand eine Idee?

Servers ersetzen: http://<ip-des-servers>/smartVISU Bei "Checking your configuration" sollte alles mit einem grünen Häckchen versehen sein. Jetzt auf den "Config" Knopf drücken. Damit müsstest du in das SmartVISU Interface gelangen, direkt auf die Config Seite. Bei I/O Connection "Smarthome.py" 

Im Prinzip diese seite

(http://tapatalk.imageshack.com/v2/14/10/15/b2aaf2116705fd640bdd0f8ebb7bc0a3.jpg)

Hallo,
die SmartVisu-Seite war nie offline, nur vorübergehen gesperrt, wahrscheinlich wegen Wartungen.

@hyper2910
Warum willst du da wieder zurück?
Grundsätzlich wird das nur einmal am Anfang angezeigt, aber eigentlich brauchst du das eh nicht.
Bei der Installationsanleitung die du verwendet hast, ist das Programm smarthome.py auch dabei, willst du das überhaupt?
smarthome.py ist auch ein Haussteuerungssystem wie FHEM, aber da du ja hier schreibst geh ich davon aus, das du FHEM hast und nur
die Weboberfläche haben willst, oder liege ich da falsch?
Lg,
Tropaion

@tropaion,  genau, möchte nur die Oberfläche nutzen.



Als I/O Connection habe ich auch nichts ausgewählt, ich gehe davon aus, das diese Modul von Hermannj gerade programmiert wird.

Ich wollte dahin zurück, da man dort bei der IMAGE Installation Smartvisu auch updaten konnte.


Gruss DIrk

Kann jemand eine klare Empfehlung abgeben, ob Apache oder lighttpd oder nginx für smartvisu zu bevorzugen ist?


Sent from my iPhone using Tapatalk

Eine klare Empfehlung kann ich nicht abgeben, aber da ich auf einem Cubietruck einen lighttpd laufen hatte, habe ich es da drauf (problemlos) installiert und das läuft prima.

Lighttpd läuft bei mir auch schon für Volkszaehler.org auf einem RasPi sehr gut! Vielleicht können wir eine gemeinsame best practice ermitteln, die dann als Empfehlung in die Doku geht... HCS kannst Du Deinen Installationsweg für lighttpd  zur Verwendung mit SmartVisu kurz beschreiben?


Sent from my iPhone using Tapatalk

Hi,

was mich noch interessiert, wäre warum man SmartVisu gewählt hat und nicht CometVisu!

Ich glaube das CometVisu sich mit dem Editor einfacher gestalten lässt.


Gruss Dirk

@herrmannj
Ich werde wahrscheinlich Apache nehmen, da ich das eig. schon immer genommen habe und gute Erfahrungen damit gemacht habe.
Jedoch glaube ich das es so ziehmlich egal ist welches man nimmt, im Grunde ist das ja nur der Interpreter.
Welches System Ressourcensparender ist werde ich noch in Erfahrung bringen, da ich einen RasPi verwende und der ja nicht dafür bekannt ist das er viele Ressourcen hat^^

@hyper2910
Es stimmt das dieses System automatisch updaten kann aber es ist trotzdem nicht zu empfehlen da bei dir jetzt smarthome.py wahrscheinlich im Hintergrund läuft und unnötig Ressourcen verbraucht. Wenn du nur SmartVisu installiert haben willst, musst du es manuell zu FHEM installieren.
Das Updaten ist ja nicht sonderlich schwer, die musst die alten Daten nur überschreiben (bis auf deine Seiten und Einstellungen natürlich).
Per FileZilla (FTP) geht das relativ schnell.

Warum SmartVisu?
Weil die Community größer ist, und es bessere Dokumentationen gibt. In CometVisu gibt es das kaum.

Lg,
Tropaion

 Gibt es zu smartVISU wirklich kein GitHub/Sourceforge Projekt? Damit kann man die Updates auch elegant organisieren...


Sent from my iPhone using Tapatalk

@hyper2910

Smartvisu sah eleganter aus. Generell sind die visu ja sehr flexibel. Bedeutet aber auch das du sowieso recht schnell die Seiten individuell anpasst, und der Editor das nicht mehr abbildet.

@bgewehr
Gibt es, ob das noch aktuell ist weiß ich nicht. Die aktualisierungszyklen scheinen aber auch nicht so zu sein das jetzt dauernd Updates anstehen.

Das Projekt von den Jungs ist ja GPl. Von daher könnten wir das später auch auf sf übernehmen. Vielleicht haben die Jungs ja eigene Pläne. Lasst uns erstmal alles zum Laufen bringen, schauen wo Anpassungen sinnvoll sind, das möglichst alle Funktionen unterstützt sind, und so weiter

Vg
Jörg

Ok! Ich starte mit lighttpd!


Sent from my iPhone using Tapatalk

@herrmannj
Was ist "GPI" und "sf", tut mir leid, ich bin nicht besonders gut bei solchen Begriffen.

Man könnte (ich halte es nicht für nötig) auch ein kleines Programm in PHP schreiben oder ein Script oder Modul für FHEM zum updaten schreiben.
Das dürfte eig. nicht allzu schwer sein.

GPL = Gnu Public License
Sf = Sourceforge

Update ist dann ganz einfach, wenn das smartVISU repository erst mal auf SF liegt...


Sent from my iPhone using Tapatalk

Gpl ist die Lizenz und sie besagt (vereinfacht) das man smartvisu verwenden und weitergeben darf. Also könnte smartvisu auch von Source Forge (sf), da liegt auch fhem, ausliefern.

Das halte ich aber nicht für sinnvoll

Vg
Jörg

@bgewehr
Selbst wenn es nicht auf Sourceforge wäre, wäre ein einfaches Updateprogramm wahrscheinlich nicht sonderlich schwer. Irgendwo ist die aktuelle Version eingetragen.
Mit PHP:
Man kann schauen ob welche Version man hat, wenn sie nicht aktuell ist, gibt man denn Downloadlink ein und klickt auf Updaten.
Denn rest macht das Programm.
Ist halt nur eine sehr einfache Lösung, aber gehen würde es.

@herrmannj
Danke ;)
Wieso findest du es nicht sinnvoll?
Möglich wäre es dann z.B das man neben FHEM gleich SmartVisu mit eingebautem Treiber inkl. update anbietet.

Jörg hat Recht. Wir sollten uns primär um die Entwicklung der Lösung und dann erst sekundär um das deployment und update management kümmern.

Also: welche Konfig sollen wir newbies empfehlen?

- RasPi oder BananaPi oder cubietruck
- Raspian (Debian)
- lighttpd oder was anderes?
- ???

Wenn wir gar keine gemeinsame best Practice finden, wird es um so schwieriger, eine Doku zu erstellen und die Hürde für Neueinsteiger steigt...


Sent from my iPhone using Tapatalk

Hallo zusammen,

ich glaube diese Lösung funktioniert ganz gut:

https://github.com/mknx/smarthome/wiki/Komplettanleitung-Installation-sh.py-,-smartVISU,-eibd-und-1-Wire

1Wie und eibd  kann man weglassen.

Danach müsste ja nur das Modul von hermannj dort rein.

/var/www/smartVISU/driver

fhem.js

und dann müssten wir mal sehen was hermannj so programmiert hat.

@bgewehr

ZitatJörg hat Recht.

Dem stimme ich zu ;)

ZitatAlso: welche Konfig sollen wir newbies empfehlen?

Der einzige Unterschied in denn System ist ja nur wie man denn Webserver aufsetzt, alles andere ist ja überall das selbe.
Und es gibt genug Tutorials/Anleitungen dazu, wie man auf denn verschiedenen Systemen aufsetzt.
Ich würde einfach eine Liste mit Requirements machen wie z.B. PHP5.x, usw. ... und FTP.
Und dann vll Links zu Tutorials für verschieden Plattformen.
Der Rest ist ja überall gleich, per FileZilla die Daten hochladen, usw. ...

@hyper2910
Wie funktioniert denn da das updaten?
Ich sehe hier nirgendwo stehen das die SmartVisu sich automatisch updaten lässt.
Vll. mein du das Programm smarthome.py bzw. das Programm kann smartvisu automatisch updaten?
Aber smarthome.py wollen wird doch nicht extra dafür installieren ;)

Lg,
Tropaion

Ich habe jetzt lighttpd verwendet:
sudo apt-get update
sudo apt-get install lighttpd
sudo apt-get install php5-common php5-cgi php5
cd /var/www
sudo lighty-enable-mod fastcgi-php
sudo service lighttpd force-reload
sudo chown www-data:www-data /var/www
sudo chmod 775 /var/www
sudo usermod -a -G www-data pi
sudo usermod -a -G www-data bananapi
sudo wget http://smartvisu.de/download/smartVISU_2.7.zip
sudo unzip smartVISU_2.7.zip
sudo rm smartVISU_2.7.zip
sudo chmod 777 smartVISU
cd smartVISU
sudo chmod 777 temp

Läuft!
(http://tapatalk.imageshack.com/v2/14/10/16/dc9566e88fd20b6ed33e0d78cd61cb67.jpg)

Sent from my iPhone using Tapatalk

Eigentlich nicht schwer, das ist ja, wie schon gesagt, bei denn meisten Devices sehr ähnlich.
Ich würde es aber über FTP machen, für die Standard-User.
Warum?
Weil, 1. Ist einfacher (und schneller?), Seiten zu erstellen und zu bearbeiten
2. Geht das Updaten einfacher
3. Kann man es einheitlicher erklären weil FTP überall gleich ist/funktioniert.
Was meint ihr?

Lg,
Tropaion

Ich habe ein wenig rumgesucht und folgende Erkenntnisse gehabt:
Ein knx System besteht aus einem Busankoppler für LAN, einer zentralen Steuereinheit (Systemgerät) und den Geräten am Bus. Alle smarten visus für knx sprechen über den Busankoppler und senden darüber in den Bus hinein.

Dass die Visu nicht integraler Teil der Zentraleinheit sein muss, ist doch damit bewiesen. Es geht nur noch um ein stabiles lesendes und schreibendes Protokoll.

Auf fhem übertragen kann man das wie folgt deuten: Fhem ist der Busankoppler für LAN und das Systemgerät für alle mit fhem kompatiblen Geräte.

Unsere Visu spricht mit fhem wie mit dem Busankoppler für LAN bei knx, nur dass fhem die Übersetzung in die diversen Befehle und Kommandos für die diversen Geräte über die .pm Module leistet.

Nun könnte man natürlich auf die Idee kommen, knx als Protokoll zu verwenden, und damit fhem als Ersatz für oder als integraler Teil einer knx Installation zu betreiben. Damit müsste auf der smartVISU Seite gar nichts besonderes gemacht werden, einen knx Treiber gibt es ja schon...

Frage: kann man ein knx-IP Protokoll Modul für fhem so schreiben, dass fhem einfach als knx Zentraleinheit verwendet wird und dann alles was für knx gemacht ist, auch mit fhem funktioniert?

http://www.knx.org/fileadmin/downloads/08%20-%20KNX%20Flyers/Grundlagenwissen%20zum%20KNX%20Standard/Grundlagenwissen_zum_KNX_Standard_German.pdf

Gesendet von meinem iPad mit Tapatalk

@bgewehr
Das hätte ich dir auch sagen können ;)
Theoretisch wäre es schon möglich, aber das wäre es nicht wert.
Da müsstest du jedem Device eine KNX-ID zuteilen, usw...
Und KNX ist eine geschloßene Gesellschaft, die ist ohnehin schon schwer mit fremden Devices zu kombinieren.
Ich denke man wäre sehr eingeschränkt in der Funkftionalität und der Aufwand wäre auch zu viel im Vergleich. (Da muss man erst mal wissen wie genau das Protokoll aufgebaut ist)
Da finde ich persöhnlich die Lösung von herrmannj viel besser.

Nur falls es interessiert:
Da es keine Debian-Pakete für ARM (Raspberry/Banana Pi) gibt, hier die Anleitung für die manuelle Erstellung von eibd:

mkdir /opt/knxd
cd /opt/knxd
mkdir pthsem
mkdir bcusdk
cd pthsem/
wget http://downloads.sourceforge.net/project/bcusdk/pthsem/pthsem_2.0.8.tar.gz
tar -xvf pthsem_2.0.8.tar.gz
cd pthsem-2.0.8/
./configure
make
make install
cd ../..
cd bcusdk/
wget http://downloads.sourceforge.net/project/bcusdk/bcusdk/bcusdk_0.0.5.tar.gz
tar -xvf bcusdk_0.0.5.tar.gz
cd bcusdk-0.0.5/
export LD_LIBRARY_PATH=/usr/local/lib
apt-get install libxml2-dev
./configure --with-pth=yes --without-pth-test --enable-onlyeibd --enable-pei16 --enable-ft12 --enable-tpuart --enable-pei16s --enable-tpuarts --enable-usb --enable-eibnetip --enable-eibnetiptunnel --enable-eibnetipserver
make
make install
cd /usr/local/bin
eibd --help

Ich weiss, das bringt uns nicht weiter, aber ich wollte es mal ausprobieren...

So interessant theoretisch FHEM als KNX/EIB Adapter ist, ist es nur Overhead ohne Mehrwert, von den vielen vielen Eigenheiten von KNX mal abgesehen.

Der Sinn von SmartVisu auf FHEM wäre ja, eine optisch ansprechende und performante Oberfläche für FHEM zu gewinnen und gerade bei den Widgets in Zukunft die Ressourcen zu bündeln.

Daher je simpler und FHEM-Interner desto besser.

Ich denke, Ihr habt Recht mit dem Overhead Argument. Dennoch lässt mich der Gedanke an eine harmonisch zusammenpassende Zukunft der Hausautomation nicht ganz los. Wenn weiterhin alle nur ihr eigenes Süppchenzeit kochen und zum Rest der Welt inkompatibel bleiben, dann wird Apple mit homekit aufgrund der Verbreitung der Endgeräte den Standard setzen. Man muss sich fragen, ob das Ergebnis dann für uns das Richtige ist...
Genug davon, machen wir SmartVISU für natives FHEM!!!


Sent from my iPhone using Tapatalk

Ich denke, Ihr habt Recht mit dem Overhead Argument. Dennoch lässt mich der Gedanke an eine harmonisch zusammenpassende Zukunft der Hausautomation nicht ganz los. Wenn weiterhin alle nur ihr eigenes Süppchenzeit kochen und zum Rest der Welt inkompatibel bleiben, dann wird Apple mit homekit aufgrund der Verbreitung der Endgeräte den Standard setzen. Man muss sich fragen, ob das Ergebnis dann für uns das Richtige ist...
Genug davon, machen wir SmartVISU für natives FHEM!!!


Sent from my iPhone using Tapatalk

Hallo @all,

ich möchte Euch einen kurzen Zwischenstand geben. Zuerst: es wird leider doch noch einige Tage bis zur alpha dauern (das ist nun mal bei FE Projekten so, der Aufwand lässt sich zu beginn nie genau genug schätzen  ;) )

insgesamt läuft es gut, der aktuelle Stand ist:

Das smartVisu Modul selbst läuft im ersten Wurf, soweit sichtbar auch robust. Device können connecten, werden (vorerst per IP) identifiziert. Disconnect, parallele Verbindungen, Verbindungsunterbrechungen etc. werden bearbeitet. Der smartVisu websocket läuft unabhängig vom fhem Hautprozess und kann damit performance Schwankungen ausgleichen. Die live Daten braucht er natürlich trotzdem vom fhem Hauptprozess.

Das Modul für die device "wächst". Die Daten von den jeweiligen smartVisu Device kommen bei der richtigen Instanz an. Im Augenblick arbeite ich am mapping der smartVisu GAD zu den fhem device und daran wie die "verbunden" und konvertiert werden.

Plots, Trigger, Dialog sowie SSL (TLS  ;) ) werden dann in späteren Versionen folgen.

soweit zum aktuellen Stand,
vg
jörg

das klingt schon alles
sehr gut. ich bin gespannt ...

gruss
  andre

@herrmannj wie machst du das mit der Aktualisierung der Status? Wird jedes fhem Gerät regelmäßig abgefragt oder teilt ein fhem Gerät seine Statusänderungen aktiv allen Devices als Ereignis mit?


Sent from my iPhone using Tapatalk

Hi,

wie meinst Du das, welchen Status  ?

vg
jörg

On oder Off einer Lampe kann sich ja von jedem Device (iPhone, iPad, at-Befehl...) aus ändern. Wie erfahren die anderen Devices (smartVisus) davon? Push oder pull?


Sent from my iPhone using Tapatalk

verstehe, mir war nicht klar ob Du das device (ipad) an sich meinst.

Antwort auf Deine Frage: push, natürlich.  :)

vg
jörg

Sehr gut! Bin gespannt auf Deine Lösung! Wann können wir mit dem Testen beginnen?


Sent from my iPhone using Tapatalk

Hallo herrmannj,
ich finde deine Lösung/Umsetzung sehr gut, so wie du es erzählt hast.
Brauchst dich aber nicht stressen, ich (wir?) sind froh das du das machst.
Ich bin gerade dabei mich wieder mit PHP aufzufrischen (war ein bisschen inaktiv) und dann werd ich mir mal js anschauen,
kann man eh immer brauchen (auch für ein anderes Projekt).

ZitatBrauchst dich aber nicht stressen, ich (wir?) sind froh das du das machst.

WIR !!!!

Lasst uns warten, auch wenns schwer fällt, es scheint sich zu lohnen.
Es wird wohl reichlich Alphatester geben, wenns so weit ist. Dann gibts sicher noch einges (mehr) zu tun.

Gruß
Kai

Zitat von: kaizo am 20 Oktober 2014, 20:29:16
...Dann gibts sicher noch einges (mehr) zu tun. ...

Das befürchte ich auch.  ;)

vg
jörg

@herrmannj
also meine volle Unterstützung hast du, wenn du was brauchst kann du gerne Fragen (ausgenommen Geld, HTL-Schüler :D).
Ansonsten bin ich recht gut ausgestattet mit Mitteln (gemieteten Webserver, Test-Rootserver usw. ...)
Was ich damit sagen will, wenn du etwas benötigst, was auch immer, frag hier nach, ich glaube du wirst viel Unterstützung bekommen, wie man hier so liest ;)

Vielen Dank.

Vg
Jörg

Zitat von: herrmannj am 19 Oktober 2014, 23:31:47
....
soweit zum aktuellen Stand,
vg
jörg

Hallo Jörg,

ich beobachten den Betrag schon eine Weile,
hört sich alles sehr gut an.
Freut mich das du dich dem Thema
annimmst  :)

Danke schon mal
Grüße Hannes

@herrmannj
Und wie gehts voran?
Gibt es Fortschritte/Hürden?

Lg,
Tropaion

Hi,

konnte die Woche leider kaum Zeit investieren. Das sollte sich kommende Woche bessern, ich hoffe auf zwei komplette Tage für das Projekt und sicher auch einige Abende.

Hürden und Stolpersteine (Folge Verzögerung) erwarte ich jetzt keine mehr (Daumendrück).

vg
Jörg

Hallo,

gibt es hier schon neue Erkenntnisse?

Hallo @all,

ZitatDas sollte sich kommende Woche bessern, ich hoffe auf zwei komplette Tage für das Projekt und sicher auch einige Abende.

Kein noch so guter Plan überlebt den ersten Feindkontakt - oder: erstens kommt es anders, zweitens als man denkt ...

Kurze Wasserstandsmeldung und eine Bitte.

Der Editor nimmt auch langsam Formen an (da geht es um die Übersetzung zwischen fhem und smartVisu).
Den Screenshot im Anhang kurz erklärt: Im oberen Teil werden die GADs aufgelistet die von smartVisu "angefragt" werden. Normalerweise stehen da viele, ich hab testweise einen drin.

Darunter kommt das mapping, darunter die permissions für das jeweilige device.

Zum mapping: welches fhem device, welches reading werden auf das GAD abgebildet. Zeile 3 (converter) konvertiert dann das fhem reading in das smartVisu format (und zurück).

Fhem bedient ja viele verschiedene hardware, auch custom made. Deswegen wird man in den 99_myUtils recht simpel eigene converter anlegen können, allerdings würde ich auch gern schon mal die wichtigen mitliefern.

Beispiel button zum besseren Verständnis
smartVisu ist hier: http://smartvisu.de/docu/2.7/index.php?page=basic/widget_basic.button

In den default Einstellungen erwartet (und sendet) das widget Werte 0/1.

Angenommen der fhem Gegenpart ist jetzt zB homeeasy (gilt für viele andere) dann ist es Aufgabe des converters den STATE (on/off) in (0/1) umzuwandeln.

Die Bitte:
schaut doch bitte schon mal was für Hardware in bedienen wollt. Ihr müsst jetzt da um Gottes willen nicht alles reinwerfen, Ziel ist es das zu ein wenig zu strukturieren. Also immer rinn in den thread damit. :-)

Am Beispiel von oben nehme ich also einen Converter der aus dem STATE "on/off" dann "0/1" macht und der erschlägt dann alle ähnlich gelagerten. Komplexere Beispiele (anderer converter) sind FS20 dimmer.

Was ich brächte sind: wozu (also zB HM dimmer), wie heißt das reading, welche Werte (0..100, mit oder ohne Einheit, etc) wie heißt das smartVisu widget das bedient werden soll und welche Werte braucht das (die meisten brauchen int, wenn unsicher schau ich auch nach).

Das wird zwar hier kurz ein durcheinander geben aber dann hoffe ich wird sich auch genauso schnell eine Struktur bilden lassen. Ich denke das am Ende auch nur wenige Converter gebraucht werden. Beispiel thermometer: ist immer eine Zahl, Einheiten weg, nach integer und mit einem Schlag gleich buchstäblich hunderte  erschlagen. Zwischen einem TX29 und einem RT-DN unterscheidet sich nur noch der Name des readings und der ist user input.

Ich hoffe ich hab mich nicht zu kompliziert ausgedrückt. In der Hauptsache geht es mir darum zu checken ob ich alle denkbaren Fälle mit dem System erschlagen kann und gleichzeitig eben schon wichtige converter reinzupacken. Der Rest wächst dann schnell (und jeder kann sich in den 99_myUtils eigene basteln wenn gewünscht)

Für Sonderfälle (attribute) die abweichen wird es noch einen Expertenmodus geben.

Danke schon mal, viele Grüße
Jörg

Also, ich muss sagen das sieht schon sehr gut aus!
Ich hab deine Erklärung jedenfalls verstanden ;)
Ich verwende derzeit nur die HM Lichtschalter (stetig am erweitern^^). Jedoch möchte ich bald einmal von der Standardfirmware dies Lichtschalter weg weil sie mir nicht gefällt.
Das wäre echt toll wenn diese dann Unterstützt wird (wird nicht sonderlich schwer sein) (Firmware: http://forum.fhem.de/index.php/topic,18071.msg119819.html#msg119819 ).
Recht viel kann ich dir jetzt darüber leider noch nicht sagen weil ich noch nicht dazugekommen damit "rumzuspielen"

Lg,
Tropaion

ja klar. "Unterstützt oder nicht" soll es nicht geben. Um das sicherzustellen ja der Aufruf.

Reading und converter reichen um alles anzusteuern. Gibt es keinen fertigen converter dann reicht ein "wenigzeiler" in der 99_myUtils. Ich hab zwar hm aber keine Schalter, schau mal was im eventmonitor gezeigt wird wenn Du den schaltest. HM ist ein wenig ein Sonderfall wegen dem set_..., da muss man den converteer nur richtig stricken dann läuft das.

vg
jörg
   

Am Event-Monitor sieht man nur "Ein" oder "Aus", weil ich es mit
statusRequest:Statusanfrage on:Ein off:Aus
geändert habe. Also eigentlich ist es on/off. Bei denn Schaltern ist noch die originalfirmware oben.

Lg,
Tropaion

Hallo,

ich lese jetzt hier schon eine ganze Weile mit und finde es gut, was es für fortschritte macht.
Da ich das Webinterface von "Standard-FHEM" nicht so toll finde würde ich wenn es dann mit SmartVisu funktioniert auf dieses Umstellen.
Die Geräte die ich damit ansteuern/ auslesen möchte wären derzeit von Homematic die Lichtschalter, Zwischenstecker, Heizkörperventile, Rollladenaktoren und der bereits in einem Beitrag weiter oben genannte Dimmer. Zudem verwende ich Funksteckdosen von InterTechno und lese meine Solaranlage via VBus aus.

viele Grüße
Alexander

Ich würde sagen, wir sollten auch mal eine Liste der möglichen Widgets erstellen und schauen was für Devices aus FHEM da dazupassen:

Szenen > FHEM dummy / notifies, 99_Utils.pm
Dimmer > FHEM Devices die dimmen (wobei FHEM hier zB mehr als das Smartvisu - Widget bietet)
RGB > die diversen RGB module
Heizung > Temperatur & Programme setzen (diverse Module von PID über FHT80 bis MAX)
Rollos > Rollos (da kenne ich mich nicht aus, habe keine, Smartvisu hat sogar 2 Widgets)
Diagramme > SVG-Standard-Diagramme / extjs Diagramme / (ich bin nach wie vor ein Fan von RRD)
Statusanzeige > Offen / Zu / Alarm
Multi-Media > Sonos, MPD, XMBC, Squeeze

Gibt es auch etwas für einen Stufenschalter?

Zum Beispiel für Lüftungsanlagen / Ventilatoren

0 I II III


Gruß,
Thorsten

Hört sich sehr sehr interessant an!!

Kann man die SMARTVISU Funktion zum Energieverbrauch (Charts) nutzen um FHEM GPLOT/SVG abzubilden?

Device:
SMLUSB
DBLOG
FILELOG

Gruss
Axel

Zitat von: axel.mohnen am 05 November 2014, 14:13:12
Hört sich sehr sehr interessant an!!

Kann man die SMARTVISU Funktion zum Energieverbrauch (Charts) nutzen um FHEM GPLOT/SVG abzubilden?

ja, plots und co werden kommen, aber erst später.

vg
jörg

Zitat von: thoweiss am 05 November 2014, 12:56:41
Gibt es auch etwas für einen Stufenschalter?

Zum Beispiel für Lüftungsanlagen / Ventilatoren

0 I II III

Hi Thorsten,

denke das sollte gehen. Auf der smartVisu Seite könntest Du zB eine control group dafür nehmen. Oder slider bzw evtl shifter.  In smartVisu läßt sich (können vorausgesetzt) ja recht viel programmieren.

In Richtung fhem kommen dann die converter ins spiel. Evtl musst Du Dir dafür einen speziellen in der 99_myUtil erstellen. Wie steuerst Du das fhem seitig jetzt an (gerne konkret die set befehle und die readings)

vg
jörg

Zitat von: drdownload am 05 November 2014, 10:39:23
Heizung > Temperatur & Programme setzen (diverse Module von PID über FHT80 bis MAX)

Hi,

vermutlich hast Du das widget schon angeschaut: http://smartvisu.de/docu/2.7/index.php?page=device/widget_device.rtr

Zwei gad mit Kernfunktionen sind
gad_actual
a gad/item for the actual temperature
gad_set
a gad/item for the set temperature
Für die zwei braucht man zwei converter:

Der erste muss die Temperatur des Zimmerthermometers holen (und pushen).
Ich denke mal das max und fht eingebaute readings dafür haben. Magst Du die einmal kurz posten bitte ?

Das zweite muss die Wunschtemp vom fht bzw max holen und setzen können. Da würde mich jeweils das reading (name und wert) interessieren und der set befehl um die desired-temp zu setzen.

danke und vg
jörg

Hallo,

Zitat von: herrmannj am 04 November 2014, 22:01:00
Am Beispiel von oben nehme ich also einen Converter der aus dem STATE "on/off" dann "0/1" macht und der erschlägt dann alle ähnlich gelagerten. Komplexere Beispiele (anderer converter) sind FS20 dimmer.

Was ich brächte sind: wozu (also zB HM dimmer), wie heißt das reading, welche Werte (0..100, mit oder ohne Einheit, etc) wie heißt das smartVisu widget das bedient werden soll und welche Werte braucht das (die meisten brauchen int, wenn unsicher schau ich auch nach).

Hast du dich evtl. schon mal mit jsonlist2 beschäftigt? Das wäre bei diesem Vorhaben vermutlich ziemlich hilfreich.
Aufruf möglich z.B. so:
http://192.168.0.123:8083/fhem?cmd=jsonlist2&XHR=1
Hier mal ein Auszug von einem meiner MAX Wandthermostate (beachte PossibleSets, PossibleAttrs und Readings ):


{
    "Name":"WZ_Wandthermostat",
    "PossibleSets":"wakeUp factoryReset groupid associate:SZ_Heizung,MAX_044201,WZ_Heizung,MAX_ShutterContact,fakeShutterContact deassociate:SZ_Heizung,MAX_044201,WZ_Heizung,MAX_ShutterContact,fakeShutterContact displayActualTemperature:0,1 desiredTemperature:eco,comfort,boost,auto,off,5.0,5.5,6.0,6.5,7.0,7.5,8.0,8.5,9.0,9.5,10.0,10.5,11.0,11.5,12.0,12.5,13.0,13.5,14.0,14.5,15.0,15.5,16.0,16.5,17.0,17.5,18.0,18.5,19.0,19.5,20.0,20.5,21.0,21.5,22.0,22.5,23.0,23.5,24.0,24.5,25.0,25.5,26.0,26.5,27.0,27.5,28.0,28.5,29.0,29.5,30.0,on ecoTemperature:off,5.0,5.5,6.0,6.5,7.0,7.5,8.0,8.5,9.0,9.5,10.0,10.5,11.0,11.5,12.0,12.5,13.0,13.5,14.0,14.5,15.0,15.5,16.0,16.5,17.0,17.5,18.0,18.5,19.0,19.5,20.0,20.5,21.0,21.5,22.0,22.5,23.0,23.5,24.0,24.5,25.0,25.5,26.0,26.5,27.0,27.5,28.0,28.5,29.0,29.5,30.0,on comfortTemperature:off,5.0,5.5,6.0,6.5,7.0,7.5,8.0,8.5,9.0,9.5,10.0,10.5,11.0,11.5,12.0,12.5,13.0,13.5,14.0,14.5,15.0,15.5,16.0,16.5,17.0,17.5,18.0,18.5,19.0,19.5,20.0,20.5,21.0,21.5,22.0,22.5,23.0,23.5,24.0,24.5,25.0,25.5,26.0,26.5,27.0,27.5,28.0,28.5,29.0,29.5,30.0,on maximumTemperature:off,5.0,5.5,6.0,6.5,7.0,7.5,8.0,8.5,9.0,9.5,10.0,10.5,11.0,11.5,12.0,12.5,13.0,13.5,14.0,14.5,15.0,15.5,16.0,16.5,17.0,17.5,18.0,18.5,19.0,19.5,20.0,20.5,21.0,21.5,22.0,22.5,23.0,23.5,24.0,24.5,25.0,25.5,26.0,26.5,27.0,27.5,28.0,28.5,29.0,29.5,30.0,on minimumTemperature:off,5.0,5.5,6.0,6.5,7.0,7.5,8.0,8.5,9.0,9.5,10.0,10.5,11.0,11.5,12.0,12.5,13.0,13.5,14.0,14.5,15.0,15.5,16.0,16.5,17.0,17.5,18.0,18.5,19.0,19.5,20.0,20.5,21.0,21.5,22.0,22.5,23.0,23.5,24.0,24.5,25.0,25.5,26.0,26.5,27.0,27.5,28.0,28.5,29.0,29.5,30.0,on measurementOffset:-3.5,-3.0,-2.5,-2.0,-1.5,-1.0,-0.5,0.0,0.5,1.0,1.5,2.0,2.5,3.0,3.5 windowOpenTemperature:off,5.0,5.5,6.0,6.5,7.0,7.5,8.0,8.5,9.0,9.5,10.0,10.5,11.0,11.5,12.0,12.5,13.0,13.5,14.0,14.5,15.0,15.5,16.0,16.5,17.0,17.5,18.0,18.5,19.0,19.5,20.0,20.5,21.0,21.5,22.0,22.5,23.0,23.5,24.0,24.5,25.0,25.5,26.0,26.5,27.0,27.5,28.0,28.5,29.0,29.5,30.0,on boostDuration:30,15,60,10,5,20,0,25 boostValveposition ",
    "PossibleAttrs":"verbose:0,1,2,3,4,5 room group comment alias eventMap userReadings IODev do_not_notify:1,0 ignore:0,1 dummy:0,1 showtime:1,0 loglevel:0,1,2,3,4,5,6 keepAuto:0,1 scanTemp:0,1 event-on-change-reading event-on-update-reading event-min-interval stateFormat DbLogExclude devStateIcon devStateStyle icon sortby webCmd widgetOverride userattr",
    "Internals": {
      "CHANGED": "null",
      "CULMAX_MSGCNT": "2209",
      "CULMAX_TIME": "2014-11-05 18:29:49",
      "DEF": "WallMountedThermostat 01c9bb",
      "LASTInputDev": "CULMAX",
      "MSGCNT": "2209",
      "NAME": "WZ_Wandthermostat",
      "NR": "49",
      "RSSI": "-65",
      "STATE": "17.0 °C",
      "TYPE": "MAX",
      "addr": "01c9bb",
      "backend": "CULMAX",
      "rferror": "0",
      "type": "WallMountedThermostat"
    },
    "Readings": {
      "TimeInformationHour": { "Value":"1", "Time":"2013-05-05 20:26:54" },
      "battery": { "Value":"ok", "Time":"2014-11-05 18:12:20" },
      "comfortTemperature": { "Value":"21", "Time":"2013-10-12 12:04:44" },
      "desiredTemperature": { "Value":"17.0", "Time":"2014-11-05 18:29:49" },
      "displayActualTemperature": { "Value":"1", "Time":"2014-11-05 18:12:20" },
      "ecoTemperature": { "Value":"17", "Time":"2013-10-12 12:04:44" },
      "firmware": { "Value":"1.0", "Time":"2014-10-26 16:12:41" },
      "groupid": { "Value":"0", "Time":"2014-10-26 16:12:41" },
      "maximumTemperature": { "Value":"on", "Time":"2013-10-12 12:04:44" },
      "measurementOffset": { "Value":"0", "Time":"2013-10-12 12:04:44" },
      "minimumTemperature": { "Value":"off", "Time":"2013-10-12 12:04:44" },
      "mode": { "Value":"manual", "Time":"2014-11-05 18:12:20" },
      "msgcnt": { "Value":"215", "Time":"2014-11-05 18:12:19" },
      "state": { "Value":"17.0 °C", "Time":"2014-11-05 18:29:49" },
      "temperature": { "Value":"18.3", "Time":"2014-11-05 18:29:49" },
      "testresult": { "Value":"0", "Time":"2014-10-26 16:12:41" },
      "windowOpenDuration": { "Value":"15", "Time":"2013-10-12 12:04:44" },
      "windowOpenTemperature": { "Value":"12", "Time":"2013-10-12 12:04:44" }
    },
    "Attributes": {
      "DbLogExclude": "mode,battery,displayActualTemperature",
      "IODev": "CULMAX",
      "event-on-change-reading": "temperature,desiredTemperature,battery",
      "room": "Wohnzimmer"
    }
  }


In den possibleSets kann man z.B. die keys erkennen, die gesetzt werden können. Den keys folgen (nach dem Doppelpunkt) sämtliche möglichen bzw erlaubten Werte (kommagetrennt).
Der Bereich Readings zeigt i.d.R. ausserdem die Werte bereits ohne Einheiten (z.B. Grad für Temperatur) an.

Vielleicht ist die Schnittstelle für dein Vorhaben hilfreich?!

Gruß!

Hallo Johannes,

vielen Dank. Json list kenne ich, das interface zu smartVisu steht auch schon, dafür wird das nicht benötigt.

Den Aufruf habe ich gestartet weil ich überprüfen muss ob ich bei dem system der converter alles bedacht habe. (user kommen auf die komischsten ideen, -> gut so  :) )

vielen Dank für das list (hilft sehr), ich setze weder MAX noch fht ein, kann mir also kein list auf ein MAX ziehen  ;).

Das reading wäre also "desiredTemperature" genauso wie das set, erforderliche Schritte 0.5°.

Das bedeutet für HM und MAX Thermostate braucht es nur einen converter (der vermutlich auch gleich fht und noch einige andere abdeckt). 

Danke und Grüße
Jörg

Zitat von: herrmannj am 05 November 2014, 19:15:19
Das reading wäre also "desiredTemperature" genauso wie das set, erforderliche Schritte 0.5°.

korrekt.

Ich hänge dir nochmal 2 Gerätschaften vom Nachbarn an, vielleicht hilfts:

{
    "Name":"FHT_0000",
    "PossibleSets":"day day-temp:on,off,6.0,6.5,7.0,7.5,8.0,8.5,9.0,9.5,10.0,10.5,11.0,11.5,12.0,12.5,13.0,13.5,14.0,14.5,15.0,15.5,16.0,16.5,17.0,17.5,18.0,18.5,19.0,19.5,20.0,20.5,21.0,21.5,22.0,22.5,23.0,23.5,24.0,24.5,25.0,25.5,26.0,26.5,27.0,27.5,28.0,28.5,29.0,29.5,30.0 desired-temp:on,off,6.0,6.5,7.0,7.5,8.0,8.5,9.0,9.5,10.0,10.5,11.0,11.5,12.0,12.5,13.0,13.5,14.0,14.5,15.0,15.5,16.0,16.5,17.0,17.5,18.0,18.5,19.0,19.5,20.0,20.5,21.0,21.5,22.0,22.5,23.0,23.5,24.0,24.5,25.0,25.5,26.0,26.5,27.0,27.5,28.0,28.5,29.0,29.5,30.0 fri-from1:time fri-from2:time fri-to1:time fri-to2:time holiday1 holiday2 hour lowtemp-offset manu-temp:on,off,6.0,6.5,7.0,7.5,8.0,8.5,9.0,9.5,10.0,10.5,11.0,11.5,12.0,12.5,13.0,13.5,14.0,14.5,15.0,15.5,16.0,16.5,17.0,17.5,18.0,18.5,19.0,19.5,20.0,20.5,21.0,21.5,22.0,22.5,23.0,23.5,24.0,24.5,25.0,25.5,26.0,26.5,27.0,27.5,28.0,28.5,29.0,29.5,30.0 minute mode mon-from1:time mon-from2:time mon-to1:time mon-to2:time month night-temp:on,off,6.0,6.5,7.0,7.5,8.0,8.5,9.0,9.5,10.0,10.5,11.0,11.5,12.0,12.5,13.0,13.5,14.0,14.5,15.0,15.5,16.0,16.5,17.0,17.5,18.0,18.5,19.0,19.5,20.0,20.5,21.0,21.5,22.0,22.5,23.0,23.5,24.0,24.5,25.0,25.5,26.0,26.5,27.0,27.5,28.0,28.5,29.0,29.5,30.0 report1 report2 sat-from1:time sat-from2:time sat-to1:time sat-to2:time sun-from1:time sun-from2:time sun-to1:time sun-to2:time thu-from1:time thu-from2:time thu-to1:time thu-to2:time tue-from1:time tue-from2:time tue-to1:time tue-to2:time wed-from1:time wed-from2:time wed-to1:time wed-to2:time windowopen-temp:on,off,6.0,6.5,7.0,7.5,8.0,8.5,9.0,9.5,10.0,10.5,11.0,11.5,12.0,12.5,13.0,13.5,14.0,14.5,15.0,15.5,16.0,16.5,17.0,17.5,18.0,18.5,19.0,19.5,20.0,20.5,21.0,21.5,22.0,22.5,23.0,23.5,24.0,24.5,25.0,25.5,26.0,26.5,27.0,27.5,28.0,28.5,29.0,29.5,30.0 year",
    "PossibleAttrs":"verbose:0,1,2,3,4,5 room group comment alias eventMap userReadings IODev do_not_notify:1,0 model:fht80b dummy:1,0 showtime:1,0 retrycount minfhtbuffer lazy tmpcorr ignore:1,0 event-on-change-reading event-on-update-reading event-min-interval stateFormat DbLogExclude devStateIcon devStateStyle icon sortby webCmd widgetOverride userattr",
    "Internals": {
      "CODE": "0000",
      "DEF": "0000",
      "NAME": "FHT_0000",
      "NR": "257",
      "STATE": "???",
      "TYPE": "FHT"
    },
    "Readings": {
    },
    "Attributes": {
      "IODev": "CUL_0",
      "room": "Unsorted"
    }
  },
  {
    "Name":"FS20_1fdf62",
    "PossibleSets":"dim06% dim100% dim12% dim18% dim25% dim31% dim37% dim43% dim50% dim56% dim62% dim68% dim75% dim81% dim87% dim93% dimdown dimup dimupdown off off-for-timer on on-100-for-timer-prev on-for-timer on-old-for-timer on-old-for-timer-prev on-till ramp-off-time ramp-on-time reset sendstate timer toggle dim:slider,0,6.25,100 blink intervals off-till",
    "PossibleAttrs":"verbose:0,1,2,3,4,5 room group comment alias eventMap userReadings IODev follow-on-for-timer:1,0 follow-on-timer do_not_notify:1,0 ignore:1,0 dummy:1,0 showtime:1,0 event-on-change-reading event-on-update-reading event-min-interval stateFormat model:dummyDimmer,dummySender,dummySimple,fs20as1,fs20as4,fs20bf,fs20bs,fs20di,fs20di10,fs20du,fs20fms,fs20hgs,fs20irl,fs20kse,fs20ls,fs20ms2,fs20pira,fs20piri,fs20piru,fs20rgbsa,fs20rst,fs20rsu,fs20s16,fs20s20,fs20s4,fs20s4a,fs20s4m,fs20s4u,fs20s4ub,fs20s8,fs20s8m,fs20sa,fs20sd,fs20si3,fs20sig,fs20sm4,fs20sm8,fs20sn,fs20sr,fs20ss,fs20st,fs20st2,fs20str,fs20su,fs20sv,fs20tc1,fs20tc6,fs20tfk,fs20tk,fs20ue1,fs20usr,fs20uts,fs20ws1,fs20ze DbLogExclude devStateIcon devStateStyle icon sortby webCmd widgetOverride userattr",
    "Internals": {
      "BTN": "62",
      "DEF": "1fdf 62",
      "NAME": "FS20_1fdf62",
      "NR": "241",
      "STATE": "???",
      "TYPE": "FS20",
      "XMIT": "1fdf"
    },
    "Readings": {
    },
    "Attributes": {
      "IODev": "CUL_0",
      "room": "Unsorted"
    }
  }


tut es, Danke. Hat der fht echt keine reading oder ist das nur weil der nicht mit fhem verheiratet ist ?

vg
jörg

Zitat von: herrmannj am 05 November 2014, 15:32:52
Wie steuerst Du das fhem seitig jetzt an (gerne konkret die set befehle und die readings)

vg
jörg

Hier mal mein jsonlist-Auszug meines Dummy für die Lüftungsanlage:


{
    "Name":"du.kwl.stufe",
    "PossibleSets":"state:Aus,Stufe_1,Stufe_2,Stufe_3",
    "PossibleAttrs":"verbose:0,1,2,3,4,5 room group comment alias eventMap userReadings setList event-on-change-reading event-on-update-reading event-min-interval stateFormat OffStateName OnStateName always_hidden custom_graph devStateIcon devStateStyle fp_EG fp_Grundriss_DG fp_Grundriss_EG fp_Grundriss_OG fp_eg fp_floorplan_DG fp_floorplan_EG fp_floorplan_OG fp_fp_test fp_image icon invertState offDevice onDevice onOffDevice room_map sortby structexclude toggleDevice webCmd webcmdDevice widgetOverride widget_name yaf_1 yaf_2 yaf_3",
    "Internals": {
      "NAME": "du.kwl.stufe",
      "NR": "60",
      "STATE": "Aus",
      "TYPE": "dummy"
    },
    "Readings": {
      "state": { "Value":"Aus", "Time":"2014-11-06 07:00:00" }
    },
    "Attributes": {
      "alias": "Lüfterstufe",
      "devStateIcon": "Aus:aus:Stufe_1 Stufe_1:stufe_1:Stufe_2 Stufe_2:stufe_2:Stufe_3 Stufe_3:stufe_3:Aus",
      "fp_floorplan_EG": "450,224,2,",
      "group": "Steuerung Lüftung",
      "room": "Lueftung",
      "setList": "state:Aus,Stufe_1,Stufe_2,Stufe_3"
    }
  },

Danke

Ich hätte da mal eine grundsätzliche Frage:

Kann ich smartvisu eigentlich schon installieren um damit zu spielen?

Bzw. wie werden Smartvisu Seiten erstellt? Die Homepage schweigt sich dazu leider aus...

hier die jsonlist von fünf unterschiedlichen hue devices und dem panstamp rgb driver board:

hue bulb
jsonlist2 HUEbulb1
{
  "Arg":"HUEbulb1",
  "Results": [
  {
    "Name":"HUEbulb1",
    "PossibleSets":"off:noArg on:noArg toggle:noArg statusRequest:noArg pct:slider,0,1,100 bri:slider,0,1,254 alert:none,select,lselect dimUp:noArg dimDown:noArg rgb:colorpicker,RGB color:slider,2000,1,6500 ct:slider,154,1,500 hue:slider,0,1,65535 sat:slider,0,1,254 xy effect:none,colorloop blink on-for-timer on-till off-for-timer intervals off-till",
    "PossibleAttrs":"verbose:0,1,2,3,4,5 room group comment alias eventMap userReadings IODev delayedUpdate:1 realtimePicker:1 color-icons:1,2 model:LCT001,LCT002,LCT003,LLC001,LLC005,LLC006,LLC007,LLC011,LLC012,LST001,LWB001,LWB003,LWB004,LWL001 subType:colordimmer,dimmer,switch event-on-change-reading event-on-update-reading event-min-interval stateFormat DbLogExclude Fenster Fenster_map LichtBuero LichtBuero_map d d1 d1_map d_map devStateIcon devStateStyle device_timeout fm_fav fm_groups fm_name fm_order fm_type fm_view fp_..UG fp_0.EG fp_1.OG fp_2.OG icon lightSceneParamsToSave lightSceneRestoreOnlyIfChanged:1,0 sortby structexclude webCmd widgetOverride userattr",
    "Internals": {
      "CHANGED": "null",
      "DEF": "1 ",
      "ID": "1",
      "INTERVAL": "60",
      "NAME": "HUEbulb1",
      "NR": "168",
      "STATE": "off",
      "TYPE": "HUEDevice",
      "modelid": "LCT001",
      "name": "HUE Bulb 1",
      "swversion": "66010820",
      "type": "Extended color light"
    },
    "Readings": {
      "alert": { "Value":"none", "Time":"2014-10-28 11:33:38" },
      "bri": { "Value":"254", "Time":"2014-10-28 11:33:38" },
      "colormode": { "Value":"xy", "Time":"2014-11-06 08:19:42" },
      "ct": { "Value":"290 (3448K)", "Time":"2014-11-06 08:19:42" },
      "effect": { "Value":"none", "Time":"2014-10-28 11:33:38" },
      "hue": { "Value":"25593", "Time":"2014-11-06 08:19:42" },
      "level": { "Value":"0 %", "Time":"2014-10-04 16:47:30" },
      "onoff": { "Value":"0", "Time":"2014-11-06 08:19:42" },
      "pct": { "Value":"0", "Time":"2014-11-06 08:19:42" },
      "reachable": { "Value":"1", "Time":"2014-11-06 08:19:42" },
      "sat": { "Value":"254", "Time":"2014-11-06 08:19:42" },
      "state": { "Value":"off", "Time":"2014-11-06 08:19:42" },
      "xy": { "Value":"0.4091,0.518", "Time":"2014-11-06 08:19:42" }
    },
    "Attributes": {
      "IODev": "bridge",
      "color-icons": "2",
      "devStateIcon": "{(HUEDevice_devStateIcon($name),\"toggle\")}",
      "fp_2.OG": "272,434,0",
      "group": "HUEDevice",
      "model": "LCT001",
      "room": "21 Büro",
      "structexclude": "allesAus:.*",
      "subType": "colordimmer",
      "webCmd": "rgb:rgb ff0000:rgb DEFF26:rgb 0000ff:toggle:on:off"
    }
  }
  ],
  "totalResultsReturned":1
}

living colors
jsonlist2 LC
{
  "Arg":"LC",
  "Results": [
  {
    "Name":"LC",
    "PossibleSets":"off:noArg on:noArg toggle:noArg statusRequest:noArg pct:slider,0,1,100 bri:slider,0,1,254 alert:none,select,lselect dimUp:noArg dimDown:noArg rgb:colorpicker,RGB color:slider,2000,1,6500 ct:slider,154,1,500 hue:slider,0,1,65535 sat:slider,0,1,254 xy effect:none,colorloop blink on-for-timer on-till off-for-timer intervals off-till",
    "PossibleAttrs":"verbose:0,1,2,3,4,5 room group comment alias eventMap userReadings IODev delayedUpdate:1 realtimePicker:1 color-icons:1,2 model:LCT001,LCT002,LCT003,LLC001,LLC005,LLC006,LLC007,LLC011,LLC012,LST001,LWB001,LWB003,LWB004,LWL001 subType:colordimmer,dimmer,switch event-on-change-reading event-on-update-reading event-min-interval stateFormat DbLogExclude Fenster Fenster_map LichtBuero LichtBuero_map d d1 d1_map d_map devStateIcon devStateStyle device_timeout fm_fav fm_groups fm_name fm_order fm_type fm_view fp_..UG fp_0.EG fp_1.OG fp_2.OG icon lightSceneParamsToSave lightSceneRestoreOnlyIfChanged:1,0 sortby structexclude webCmd widgetOverride userattr",
    "Internals": {
      "CHANGED": "null",
      "DEF": "4 ",
      "ID": "4",
      "INTERVAL": "60",
      "NAME": "LC",
      "NR": "167",
      "STATE": "off",
      "TYPE": "HUEDevice",
      "modelid": "LLC006",
      "name": "LC 1",
      "swversion": "4.6.0.8274",
      "type": "Color light"
    },
    "Readings": {
      "alert": { "Value":"none", "Time":"2014-10-28 11:33:38" },
      "bri": { "Value":"0", "Time":"2014-11-06 08:18:38" },
      "colormode": { "Value":"hs", "Time":"2014-10-28 11:33:38" },
      "effect": { "Value":"none", "Time":"2014-10-28 11:33:38" },
      "hue": { "Value":"22764", "Time":"2014-10-28 11:33:38" },
      "level": { "Value":"0 %", "Time":"2014-10-03 22:43:56" },
      "onoff": { "Value":"0", "Time":"2014-11-06 08:17:38" },
      "pct": { "Value":"0", "Time":"2014-11-06 08:17:38" },
      "reachable": { "Value":"1", "Time":"2014-10-28 11:33:38" },
      "sat": { "Value":"182", "Time":"2014-10-28 11:33:38" },
      "state": { "Value":"off", "Time":"2014-11-06 08:17:38" },
      "xy": { "Value":"0.3198,0.5895", "Time":"2014-10-28 11:33:38" }
    },
    "Attributes": {
      "IODev": "bridge",
      "color-icons": "2",
      "devStateIcon": "{(HUEDevice_devStateIcon($name),\"toggle\")}",
      "fp_2.OG": "413,379,0,",
      "group": "HUEDevice",
      "model": "LLC006",
      "room": "21 Büro",
      "structexclude": "allesAus:.*",
      "subType": "colordimmer",
      "webCmd": "rgb:rgb ff0000:rgb 98FF23:rgb 0000ff:toggle:on:off"
    }
  }
  ],
  "totalResultsReturned":1
}

living whites steckdosen adapterjsonlist2 vitrine
{
  "Arg":"vitrine",
  "Results": [
  {
    "Name":"vitrine",
    "PossibleSets":"off:noArg on:noArg toggle:noArg statusRequest:noArg pct:slider,0,1,100 bri:slider,0,1,254 alert:none,select,lselect dimUp:noArg dimDown:noArg blink on-for-timer on-till off-for-timer intervals off-till",
    "PossibleAttrs":"verbose:0,1,2,3,4,5 room group comment alias eventMap userReadings IODev delayedUpdate:1 realtimePicker:1 color-icons:1,2 model:LCT001,LCT002,LCT003,LLC001,LLC005,LLC006,LLC007,LLC011,LLC012,LST001,LWB001,LWB003,LWB004,LWL001 subType:colordimmer,dimmer,switch event-on-change-reading event-on-update-reading event-min-interval stateFormat DbLogExclude Fenster Fenster_map LichtBuero LichtBuero_map d d1 d1_map d_map devStateIcon devStateStyle device_timeout fm_fav fm_groups fm_name fm_order fm_type fm_view fp_..UG fp_0.EG fp_1.OG fp_2.OG icon lightSceneParamsToSave lightSceneRestoreOnlyIfChanged:1,0 sortby structexclude webCmd widgetOverride userattr",
    "Internals": {
      "CHANGED": "null",
      "DEF": "7 ",
      "ID": "7",
      "INTERVAL": "60",
      "NAME": "vitrine",
      "NR": "340",
      "STATE": "off",
      "TYPE": "HUEDevice",
      "modelid": "LWL001",
      "name": "Dimmable plug-in unit 2",
      "swversion": "1.0.1.4591",
      "type": "Dimmable plug-in unit"
    },
    "Readings": {
      "alert": { "Value":"none", "Time":"2014-10-28 11:33:38" },
      "bri": { "Value":"0", "Time":"2014-10-28 11:33:38" },
      "effect": { "Value":"none", "Time":"2014-10-28 11:33:38" },
      "level": { "Value":"0 %", "Time":"2014-10-04 16:52:00" },
      "onoff": { "Value":"0", "Time":"2014-10-28 11:33:38" },
      "pct": { "Value":"0", "Time":"2014-10-28 11:33:38" },
      "reachable": { "Value":"1", "Time":"2014-10-28 11:33:38" },
      "state": { "Value":"off", "Time":"2014-10-28 11:33:38" }
    },
    "Attributes": {
      "IODev": "bridge",
      "devStateIcon": "{(HUEDevice_devStateIcon($name),\"toggle\")}",
      "fp_2.OG": "320,535,0,",
      "group": "HUEDevice",
      "model": "LWL001",
      "room": "21 Büro",
      "subType": "dimmer",
      "webCmd": "pct:::toggle:on:off"
    }
  }
  ],
  "totalResultsReturned":1
}

living whites energiespaar lampejsonstlist2 HUEDevice8
Unknown command jsonstlist2, try help.
jsonlist2 HUEDevice8
{
  "Arg":"HUEDevice8",
  "Results": [
  {
    "Name":"HUEDevice8",
    "PossibleSets":"off:noArg on:noArg toggle:noArg statusRequest:noArg pct:slider,0,1,100 bri:slider,0,1,254 alert:none,select,lselect dimUp:noArg dimDown:noArg blink on-for-timer on-till off-for-timer intervals off-till",
    "PossibleAttrs":"verbose:0,1,2,3,4,5 room group comment alias eventMap userReadings IODev delayedUpdate:1 realtimePicker:1 color-icons:1,2 model:LCT001,LCT002,LCT003,LLC001,LLC005,LLC006,LLC007,LLC011,LLC012,LST001,LWB001,LWB003,LWB004,LWL001 subType:colordimmer,dimmer,switch event-on-change-reading event-on-update-reading event-min-interval stateFormat DbLogExclude Fenster Fenster_map LichtBuero LichtBuero_map d d1 d1_map d_map devStateIcon devStateStyle device_timeout fm_fav fm_groups fm_name fm_order fm_type fm_view fp_..UG fp_0.EG fp_1.OG fp_2.OG icon lightSceneParamsToSave lightSceneRestoreOnlyIfChanged:1,0 sortby structexclude webCmd widgetOverride userattr",
    "Internals": {
      "CHANGED": "null",
      "DEF": "8 ",
      "ID": "8",
      "INTERVAL": "60",
      "NAME": "HUEDevice8",
      "NR": "358",
      "STATE": "unreachable",
      "TYPE": "HUEDevice",
      "modelid": "LWB001",
      "name": "Dimmable light 1",
      "swversion": "0.17.4.5162",
      "type": "Dimmable light"
    },
    "Readings": {
      "alert": { "Value":"none", "Time":"2014-10-28 11:33:39" },
      "bri": { "Value":"0", "Time":"2014-10-28 11:33:39" },
      "effect": { "Value":"none", "Time":"2014-10-28 11:33:39" },
      "level": { "Value":"0 %", "Time":"2014-10-03 11:52:36" },
      "onoff": { "Value":"0", "Time":"2014-10-28 11:33:39" },
      "pct": { "Value":"0", "Time":"2014-10-28 11:33:39" },
      "reachable": { "Value":"0", "Time":"2014-10-28 11:33:39" },
      "state": { "Value":"unreachable", "Time":"2014-10-28 11:33:39" }
    },
    "Attributes": {
      "IODev": "bridge",
      "alias": "Dimmable light 1",
      "color-icons": "2",
      "devStateIcon": "{(HUEDevice_devStateIcon($name),\"toggle\")}",
      "group": "HUEDevice",
      "model": "LWB001",
      "room": "56 HUEDevice",
      "subType": "dimmer",
      "webCmd": "pct:toggle:on:off"
    }
  }
  ],
  "totalResultsReturned":1
}

hue luxjsonlist2 HUEDevice9
{
  "Arg":"HUEDevice9",
  "Results": [
  {
    "Name":"HUEDevice9",
    "PossibleSets":"off:noArg on:noArg toggle:noArg statusRequest:noArg pct:slider,0,1,100 bri:slider,0,1,254 alert:none,select,lselect dimUp:noArg dimDown:noArg blink on-for-timer on-till off-for-timer intervals off-till",
    "PossibleAttrs":"verbose:0,1,2,3,4,5 room group comment alias eventMap userReadings IODev delayedUpdate:1 realtimePicker:1 color-icons:1,2 model:LCT001,LCT002,LCT003,LLC001,LLC005,LLC006,LLC007,LLC011,LLC012,LST001,LWB001,LWB003,LWB004,LWL001 subType:colordimmer,dimmer,switch event-on-change-reading event-on-update-reading event-min-interval stateFormat DbLogExclude Fenster Fenster_map LichtBuero LichtBuero_map d d1 d1_map d_map devStateIcon devStateStyle device_timeout fm_fav fm_groups fm_name fm_order fm_type fm_view fp_..UG fp_0.EG fp_1.OG fp_2.OG icon lightSceneParamsToSave lightSceneRestoreOnlyIfChanged:1,0 sortby structexclude webCmd widgetOverride userattr",
    "Internals": {
      "CHANGED": "null",
      "DEF": "9 ",
      "ID": "9",
      "INTERVAL": "60",
      "NAME": "HUEDevice9",
      "NR": "473",
      "STATE": "unreachable",
      "TYPE": "HUEDevice",
      "modelid": "LWB004",
      "name": "Lux Lamp 1",
      "swversion": "66012040",
      "type": "Dimmable light"
    },
    "Readings": {
      "alert": { "Value":"none", "Time":"2014-10-28 11:33:42" },
      "bri": { "Value":"0", "Time":"2014-10-28 11:33:42" },
      "effect": { "Value":"none", "Time":"2014-10-28 11:33:42" },
      "level": { "Value":"0 %", "Time":"2014-10-04 17:19:57" },
      "onoff": { "Value":"0", "Time":"2014-10-28 11:33:42" },
      "pct": { "Value":"0", "Time":"2014-10-28 11:33:42" },
      "reachable": { "Value":"0", "Time":"2014-10-28 11:33:42" },
      "state": { "Value":"unreachable", "Time":"2014-10-28 11:33:42" }
    },
    "Attributes": {
      "IODev": "bridge",
      "alias": "Lux Lamp 1",
      "devStateIcon": "{(HUEDevice_devStateIcon($name),\"toggle\")}",
      "model": "LWB004",
      "room": "56 HUEDevice",
      "subType": "dimmer",
      "webCmd": "pct:toggle:on:off"
    }
  }
  ],
  "totalResultsReturned":1
}

panstamp rgbjsonlist2 SWAP_BB
{
  "Arg":"SWAP_BB",
  "Results": [
  {
    "Name":"SWAP_BB",
    "PossibleSets":"regGet regSet statusRequest:noArg readDeviceXML:noArg clearUnconfirmed:noArg dimDown:noArg dimUp:noArg fadeTo getFade getIR learnIR off:noArg on:noArg on-for-timer reset:noArg rgb:colorpicker,RGB sendIR setFade setIR startFade storeIR toggle:noArg blink on-till off-for-timer intervals off-till",
    "PossibleAttrs":"verbose:0,1,2,3,4,5 room group comment alias eventMap userReadings IODev ignore:1,0 event-on-change-reading event-on-update-reading event-min-interval stateFormat ProductCode:0000000100000001,0000000100000002,0000000100000003,0000000100000004,0000000100000005,0000000100000006,0000000100000007,0000000100000008,0000000100000009,000000010000000A,000000010000000B,000000010000000C,000000010000000D,000000010000000E,0000001100000001,0000001100000002,0000001100000003,0000001100000004,0000001100000005,0000001600000001,0000001900000001,0000001B00000001,0000001D00000001,0000002200000003,0000002200000007,0000002200000008,000000220000000F,0000002200000010,00000022FFFFFFFF color-icons:1,2 defaultFadeTime DbLogExclude Fenster Fenster_map LichtBuero LichtBuero_map d d1 d1_map d_map devStateIcon devStateStyle device_timeout fm_fav fm_groups fm_name fm_order fm_type fm_view fp_..UG fp_0.EG fp_1.OG fp_2.OG icon lightSceneParamsToSave lightSceneRestoreOnlyIfChanged:1,0 sortby structexclude webCmd widgetOverride userattr",
    "Internals": {
      "CHANNELS": "3",
      "CMD_SIZE": "6",
      "DEF": "BB 0000002200000003",
      "Developer": "justme",
      "LASTInputDev": "panStamp",
      "MSGCNT": "11135",
      "NAME": "SWAP_BB",
      "NR": "416",
      "Product": "RGB driver board with IR",
      "STATE": "off",
      "SWAP_00-ProductCode": "0000002200000003",
      "SWAP_00.1-ManufacturerID": "00000022",
      "SWAP_00.2-ProductID": "00000003",
      "SWAP_01-HardwareVersion": "00000101",
      "SWAP_02-FirmwareVersion": "00000100",
      "SWAP_03-SystemState": "01",
      "SWAP_04-FrequencyChannel": "00",
      "SWAP_05-SecurityOption": "00",
      "SWAP_06-SecurityPassword": "00",
      "SWAP_07-SecurityNonce": "4C",
      "SWAP_08-NetworkID": "B547",
      "SWAP_09-DeviceAddress": "BB",
      "SWAP_0A-PeriodicTxInterval": "0320",
      "SWAP_MISSED": "2",
      "SWAP_Sent_unconfirmed": "3 Sent_unconfirmed",
      "SWAP_lastRcv": "2014-11-06 10:09:59",
      "SWAP_lastSend": "2014-11-06 08:49:47",
      "SWAP_nonce": "86",
      "TYPE": "SWAP_0000002200000003",
      "addr": "BB",
      "devices": "null",
      "nonce": "3",
      "panStamp_LQI": "46",
      "panStamp_MSGCNT": "11138",
      "panStamp_RAWMSG": "(ED2E)00BB008600BB110022",
      "panStamp_RSSI": "-83.5",
      "panStamp_TIME": "2014-11-06 10:09:59"
    },
    "Readings": {
      "0B-RGBlevel": { "Value":"000000", "Time":"2014-11-06 10:09:59" },
      "0B.1-Red": { "Value":"00", "Time":"2014-11-06 10:09:59" },
      "0B.2-Green": { "Value":"00", "Time":"2014-11-06 10:09:59" },
      "0B.3-Blue": { "Value":"00", "Time":"2014-11-06 10:09:59" },
      "0B.4-White": { "Value":"", "Time":"2014-10-28 15:12:37" },
      "0C-IRCommand": { "Value":"FFD42A1E57", "Time":"2014-10-28 15:12:37" },
      "0C.1-Type": { "Value":"FF", "Time":"2014-10-28 15:12:37" },
      "0C.2-Value": { "Value":"D42A1E57", "Time":"2014-10-28 15:12:37" },
      "0D-InternalTemperature": { "Value":"0000001B", "Time":"2014-11-06 10:09:59" },
      "0E-PowerOnState": { "Value":"03FF403C00", "Time":"2014-11-06 08:20:09" },
      "0E.1-State": { "Value":"03", "Time":"2014-11-06 08:20:09" },
      "0E.2-Brightness": { "Value":"FF", "Time":"2014-11-06 08:20:09" },
      "0E.3-Color": { "Value":"403C00", "Time":"2014-11-06 08:20:09" },
      "0F-Command": { "Value":"000000000000", "Time":"2014-10-29 20:55:58" },
      "0F.1-Cmd": { "Value":"00", "Time":"2014-10-29 20:55:58" },
      "0F.2-Args": { "Value":"0000000000", "Time":"2014-10-29 20:55:58" },
      "10-Maximum_hop": { "Value":"00", "Time":"2014-10-26 18:07:08" },
      "11-Brightness": { "Value":"0022", "Time":"2014-11-06 10:09:59" },
      "brightness": { "Value":"34", "Time":"2014-11-06 10:09:59" },
      "internaltemperature": { "Value":"27", "Time":"2014-11-06 10:09:59" },
      "state": { "Value":"off", "Time":"2014-11-06 10:09:59" }
    },
    "Attributes": {
      "IODev": "panStamp",
      "ProductCode": "0000002200000003",
      "devStateIcon": "{(SWAP_0000002200000003_devStateIcon($name),\"toggle\")}",
      "room": "53 SWAP,22 Wohnzimmer",
      "userReadings": "internaltemperature:0D-InternalTemperature {hex(ReadingsVal($name,\"0D-InternalTemperature\",\"0\"))}, brightness:11-Brightness {hex(ReadingsVal($name,\"11-Brightness\",\"0\"))}",
      "webCmd": "rgb:rgb ff0000:rgb 00ff00:rgb 0000ff:toggle:on:off"
    }
  }
  ],
  "totalResultsReturned":1
}

gruss
andre

Max Komponenten:

   "Name":"Esszimmer",
    "PossibleSets":"wakeUp factoryReset groupid associate:Flur_Unten,Esszimmer_WindowSensor,BZ_Fenster,WZ_Terasse1,Flur_Oben,Arbeitszimmer,Garage,oelzaehler,Schlafzimmer,MAX_04ee5b,WZ_Shutter1,Kuechenfenster,Fenster_FlurOben,WZ_Terasse,Glicht,WZ_Hofseite,Badezimmer,Kueche,Wohnzimmer,SZ_Shutter1,fakeWallThermostat,fakeShutterContact deassociate:Flur_Unten,Esszimmer_WindowSensor,BZ_Fenster,WZ_Terasse1,Flur_Oben,Arbeitszimmer,Garage,oelzaehler,Schlafzimmer,MAX_04ee5b,WZ_Shutter1,Kuechenfenster,Fenster_FlurOben,WZ_Terasse,Glicht,WZ_Hofseite,Badezimmer,Kueche,Wohnzimmer,SZ_Shutter1,fakeWallThermostat,fakeShutterContact desiredTemperature:eco,comfort,boost,auto,off,5.0,5.5,6.0,6.5,7.0,7.5,8.0,8.5,9.0,9.5,10.0,10.5,11.0,11.5,12.0,12.5,13.0,13.5,14.0,14.5,15.0,15.5,16.0,16.5,17.0,17.5,18.0,18.5,19.0,19.5,20.0,20.5,21.0,21.5,22.0,22.5,23.0,23.5,24.0,24.5,25.0,25.5,26.0,26.5,27.0,27.5,28.0,28.5,29.0,29.5,30.0,on measurementOffset:-3.5,-3.0,-2.5,-2.0,-1.5,-1.0,-0.5,0.0,0.5,1.0,1.5,2.0,2.5,3.0,3.5 windowOpenDuration boostDuration:30,15,60,10,5,20,0,25 boostValveposition decalcification maxValveSetting valveOffset weekProfile",
    "PossibleAttrs":"verbose:0,1,2,3,4,5 room group comment alias eventMap userReadings IODev do_not_notify:1,0 ignore:0,1 dummy:0,1 showtime:1,0 loglevel:0,1,2,3,4,5,6 keepAuto:0,1 scanTemp:0,1 event-on-change-reading event-on-update-reading event-min-interval stateFormat Personen Personen_map devStateIcon devStateStyle icon sortby structexclude webCmd widgetOverride userattr",
    "Internals": {
      "CFGFN": "/opt/fhem/FHEM/CLUMAX.cfg",
      "CULMAX0_MSGCNT": "13",
      "CULMAX0_TIME": "2014-11-06 14:21:00",
      "DEF": "HeatingThermostat 071025",
      "LASTInputDev": "CULMAX0",
      "MSGCNT": "13",
      "NAME": "Esszimmer",
      "NR": "331",
      "RSSI": "-45.5",
      "STATE": "17.0 °C",
      "TYPE": "MAX",
      "addr": "071025",
      "backend": "CULMAX0",
      "dstsetting": "1",
      "mode": "0",
      "rferror": "0",
      "type": "HeatingThermostat"
    },
    "Readings": {
      "TimeInformationHour": { "Value":"2", "Time":"2014-07-31 20:24:09" },
      "battery": { "Value":"ok", "Time":"2014-11-06 14:20:59" },
      "boostDuration": { "Value":"25", "Time":"2014-08-17 13:14:26" },
      "boostValveposition": { "Value":"80", "Time":"2014-08-17 13:14:26" },
      "comfortTemperature": { "Value":"21.0", "Time":"2014-08-17 13:14:26" },
      "decalcification": { "Value":"Sat 12:00", "Time":"2014-08-17 13:14:26" },
      "desiredTemperature": { "Value":"17.0", "Time":"2014-11-06 14:20:59" },
      "ecoTemperature": { "Value":"17.0", "Time":"2014-08-17 13:14:26" },
      "firmware": { "Value":"1.8", "Time":"2014-08-17 13:14:26" },
      "groupid": { "Value":"0", "Time":"2014-08-17 13:14:26" },
      "maxValveSetting": { "Value":"100", "Time":"2014-08-17 13:14:26" },
      "maximumTemperature": { "Value":"on", "Time":"2014-08-17 13:14:26" },
      "measurementOffset": { "Value":"0.0", "Time":"2014-08-17 13:14:26" },
      "minimumTemperature": { "Value":"off", "Time":"2014-08-17 13:14:26" },
      "mode": { "Value":"auto", "Time":"2014-11-06 14:20:59" },
      "msgcnt": { "Value":"187", "Time":"2014-11-06 14:18:50" },
      "state": { "Value":"17.0 °C", "Time":"2014-11-06 14:21:00" },
      "temperature": { "Value":"18.6", "Time":"2014-11-06 12:00:37" },
      "testresult": { "Value":"255", "Time":"2014-08-17 13:14:26" },
      "valveOffset": { "Value":"0", "Time":"2014-08-17 13:14:26" },
      "valveposition": { "Value":"9", "Time":"2014-11-06 14:20:59" },
      "weekprofile-0-Sat-temp": { "Value":"17.0 °C  /  21.0 °C  /  17.0 °C", "Time":"2014-11-06 14:21:00" },
      "weekprofile-0-Sat-time": { "Value":"00:00-09:00  /  09:00-22:00  /  22:00-00:00", "Time":"2014-11-06 14:21:00" },
      "weekprofile-1-Sun-temp": { "Value":"17.0 °C  /  21.0 °C  /  17.0 °C", "Time":"2014-11-06 14:21:00" },
      "weekprofile-1-Sun-time": { "Value":"00:00-09:10  /  09:10-21:00  /  21:00-00:00", "Time":"2014-11-06 14:21:00" },
      "weekprofile-2-Mon-temp": { "Value":"17.0 °C  /  21.5 °C  /  17.0 °C", "Time":"2014-11-06 14:21:00" },
      "weekprofile-2-Mon-time": { "Value":"00:00-16:20  /  16:20-21:50  /  21:50-00:00", "Time":"2014-11-06 14:21:00" },
      "weekprofile-3-Tue-temp": { "Value":"17.0 °C  /  21.0 °C  /  17.0 °C", "Time":"2014-11-06 14:21:00" },
      "weekprofile-3-Tue-time": { "Value":"00:00-16:00  /  16:00-21:00  /  21:00-00:00", "Time":"2014-11-06 14:21:00" },
      "weekprofile-4-Wed-temp": { "Value":"17.0 °C  /  21.0 °C  /  17.0 °C", "Time":"2014-11-06 14:21:00" },
      "weekprofile-4-Wed-time": { "Value":"00:00-16:00  /  16:00-21:00  /  21:00-00:00", "Time":"2014-11-06 14:21:00" },
      "weekprofile-5-Thu-temp": { "Value":"17.0 °C  /  21.5 °C  /  17.0 °C", "Time":"2014-11-06 14:21:00" },
      "weekprofile-5-Thu-time": { "Value":"00:00-16:00  /  16:00-21:00  /  21:00-00:00", "Time":"2014-11-06 14:21:00" },
      "weekprofile-6-Fri-temp": { "Value":"17.0 °C  /  21.0 °C  /  17.0 °C", "Time":"2014-11-06 14:21:00" },
      "weekprofile-6-Fri-time": { "Value":"00:00-16:00  /  16:00-21:00  /  21:00-00:00", "Time":"2014-11-06 14:21:00" },
      "windowOpenDuration": { "Value":"15", "Time":"2014-08-17 13:14:26" },
      "windowOpenTemperature": { "Value":"12.0", "Time":"2014-08-17 13:14:26" }
    },


2.Max  Shutter

{
    "Name":"Kuechenfenster",
    "PossibleSets":"wakeUp factoryReset groupid associate:Flur_Unten,Flur_Oben,Arbeitszimmer,Schlafzimmer,WZ_Terasse,Glicht,WZ_Hofseite,Badezimmer,Kueche,Wohnzimmer,Esszimmer deassociate:Flur_Unten,Flur_Oben,Arbeitszimmer,Schlafzimmer,WZ_Terasse,Glicht,WZ_Hofseite,Badezimmer,Kueche,Wohnzimmer,Esszimmer",
    "PossibleAttrs":"verbose:0,1,2,3,4,5 room group comment alias eventMap userReadings IODev do_not_notify:1,0 ignore:0,1 dummy:0,1 showtime:1,0 loglevel:0,1,2,3,4,5,6 keepAuto:0,1 scanTemp:0,1 event-on-change-reading event-on-update-reading event-min-interval stateFormat Personen Personen_map devStateIcon devStateStyle icon sortby structexclude webCmd widgetOverride userattr",
    "Internals": {
      "CFGFN": "/opt/fhem/FHEM/maxcube.cfg",
      "CULMAX0_MSGCNT": "3",
      "CULMAX0_TIME": "2014-11-06 13:55:48",
      "DEF": "ShutterContact 073e00",
      "LASTInputDev": "MAXCube",
      "MAXCube_MSGCNT": "171",
      "MAXCube_TIME": "2014-11-06 14:36:50",
      "MSGCNT": "174",
      "NAME": "Kuechenfenster",
      "NR": "200",
      "RSSI": "-71",
      "STATE": "closed",
      "TYPE": "MAX",
      "addr": "073e00",
      "backend": "MAXCube",
      "rferror": "0",
      "serial": "KEQ0190155",
      "type": "ShutterContact"
    },





RGB Modul

  "Name":"Lichtleiste",
    "PossibleSets":"aus Mitte Aussen on off dim dimup dimdown HSV RGB sync pair unpair",
    "PossibleAttrs":"verbose:0,1,2,3,4,5 room group comment alias eventMap userReadings widget:0,1 gamma dimStep defaultColor Personen Personen_map devStateIcon devStateStyle icon sortby structexclude webCmd widgetOverride userattr",
    "Internals": {
      "CFGFN": "/opt/fhem/FHEM/wifiled.cfg",
      "CONNECTION": "bridge-V3",
      "DEF": "RGBW2 bridge-V3:192.168.178.35",
      "IP": "192.168.178.35",
      "LEDTYPE": "RGBW2",
      "NAME": "Lichtleiste",
      "NR": "127",
      "PORT": "8899",
      "SLOT": "8",
      "STATE": "aus",
      "TYPE": "WifiLight"
    },
    "Readings": {
      "BRIGHTNESS": { "Value":"0", "Time":"2014-11-05 22:30:01" },
      "HUE": { "Value":"0", "Time":"2014-11-05 22:30:01" },
      "RGB": { "Value":"000000", "Time":"2014-11-05 22:30:01" },
      "SATURATION": { "Value":"0", "Time":"2014-11-05 22:30:01" },
      "brightness": { "Value":"0", "Time":"2014-10-30 22:30:00" },
      "hue": { "Value":"0", "Time":"2014-10-30 22:30:00" },
      "saturation": { "Value":"0", "Time":"2014-10-30 22:30:00" },
      "state": { "Value":"off", "Time":"2014-11-05 22:30:01" }
    },
    "Attributes": {
      "defaultColor": "0,0,50",
      "eventMap": "/HSV 0,0,100:alle an/off:aus/HSV 120,100,30:Mitte/HSV 0,0,50:alle 50%/HSV 300,100,50:Aussen",
      "group": "SchalterDraussen",
      "icon": "light_downlight",
      "room": "4.00 Draussen",
      "webCmd": "alle 50%:aus:Mitte:Aussen:alle an"
    }
  },


Zitat von: thoweiss am 06 November 2014, 09:47:02
Ich hätte da mal eine grundsätzliche Frage:

Kann ich smartvisu eigentlich schon installieren um damit zu spielen?

Bzw. wie werden Smartvisu Seiten erstellt? Die Homepage schweigt sich dazu leider aus...

Hi,

kannst Du, bekommst halt noch keine Reaktionen von fhem dazu. Ich habe mir dort das raspi image geladen und teste ausschließlich mit den Demo Installationen (sind mehrere drauf)

Zu smartVisu (wie mache ich Seiten), kann ich bisher kaum was beitragen. Ich habe mir das genau so tief angeschaut wie notwendig für die fhem Anbindung.

Wenn Du da Lust hast Dich damit zu beschäftigen dann wär das cool. Bitte auch Erkenntnisse hier in den thread. Außerdem glaub ich das know how zum Thema "wie erstelle ich da ein widget" sehr hilfreich wäre. Wenn das erstmal läuft wird es nicht lange dauern bis wir da irgendwas anbinden wollen wo es kein widget für gibt.

vg
jörg

@hermannj
Mit dem erstellen von Seiten hab ich mich jetzt schon etwas beschäftigt. So schwer ist es gar nicht eine kleine Seite hinzubekommen für denn Anfang. Vll. kann ich ja mal am WE etwas dazu schreiben. Da bin ich auch bei einem Freund der dieses System im Dauerbetrieb verwendet. Was genau wollt ihr denn wissen/braucht ihr denn?

Mfg,
Tropaion

Hallo zusammen,

vielen Dank für die zahlreichen device list, war gut. So Geschichten wie den Stufenschalter hätte ich nicht sofort in meine Denke parat gehabt  ;). Da kommen dann sicher im laufenden Betrieb noch die eine oder andere "exotische" Geschichte dazu.

Resume so weit ist das sich die Sachen die wir jetzt hier hatten mMn alle abbilden lassen (und das galt es ja zu verifizieren). Die Hoffnung das man am Ende auch gar nicht so viele unterschiedliche converter braucht scheint sich auch zu bestätigen:

#1 die Heizungsgeschichten über die verschiedenen System (also ist-temp, soll temp-etc) lassen sich mit einem converter abbilden: Zahl rein, ein wenig umwandeln, Zahl raus. Vielleicht noch auf 0.5° anpassen. Geht dann auch für Thermometer
#2 on/off und an/aus in 1/0 (entweder als ein converter mit parameter, vielleicht auch zwei wegen "on" vs. "an")
#3 muss dann ein reading / event auf einen string testen, wenn vorhanden dann "1" sonst "0". Den braucht man bei Heizung (in einem reading stehen entweder night/comfort/frost etc - in sv sind das drei getrennte gads. Der würde auch beim Stufen-Schalter-Beispiel zum Einsatz kommen sowie Motion detector etc)
# 4 die RGBs. Alle die ich jetzt gesehen habe scheinen zu passen, RGB rein, Kanäle trennen auf 3 gads raus. Da muss ich nochmal ein wenig denken weil der Rückweg (sv -> fhem) etwas tricky ist. sv schickt alle drei Kanäle getrennt und nacheinander. Das würde erst mal bedeuten das für einmal Farbe setzen nacheinander erst r dann g dann b auf die Lampe geschickt wird. Das wäre optisch ein wenig doof, da muss ich nochmal schauen wie man das intelligent lösen kann.
#5 wären die dimmer also 0..100 auf der fhem seite
#6 Sonderlocke FS20 dimmer wegen der doofen dimsteps.

Das soll und muss jetzt keine vollständige Liste sein (weil, der user kann ja selber converter in die 99_myUtils schreiben und die Liste wird auch wachsen), aber ist schon mal eine Richtschnur.

Was ich dadurch noch gelernt habe ist das die Situation 1 reading / mehrere gad öfter auftaucht als ich dachte. Das umgekehrte Beispiel ( 1 gad gehört zu verschiedenen fhem readings) habe ich noch nicht gefunden.

Wenn jemand noch was anderes hat, gerne rein damit.

vg
jörg

Zitat von: Tropaion am 06 November 2014, 21:03:35
@hermannj
Mit dem erstellen von Seiten hab ich mich jetzt schon etwas beschäftigt. So schwer ist es gar nicht eine kleine Seite hinzubekommen für denn Anfang. Vll. kann ich ja mal am WE etwas dazu schreiben. Da bin ich auch bei einem Freund der dieses System im Dauerbetrieb verwendet. Was genau wollt ihr denn wissen/braucht ihr denn?

Mfg,
Tropaion

Hi, danke.

kann da nur für mich sprechen. Mir fehlen die Grundlagen wo ich beim Seitenaufbau starten müsste. Ich habe gelesen man soll die base Seiten in ein neues Verzeichnis kopieren und die dann anpassen. Das ist der Punkt wo es für mich anfängt und ich lernen muss   ;)

vg
jörg

Ja, das stimmt schon so, aber Anhand der Beispiele kann man sich recht gut herleiten, wie es funktioniert.

Hi,

bis wann kann man denn mit dem Treiber rechnen? Würde diesen auch gern testen. Benutze HomeMatic (Intel Nuc - Server) und GPIO vom Rasp (Slave).

Hi,

bin leider im Augenblick anderweitig recht eingespannt. Zum Glück ist der Stand in dem Projekt schon ganz passabel -> Antwort "in Kürze"

vg
jörg

Das klingt gut.


Ich habe mal ein wenig mit smartVISU gespielt - das erstellen von Seiten ist relativ einfach.

Mal sehen ob ich dazu etwas zusammenschreiben kann.

Gruß,
Thorsten

Hallo Jörg,

ich habe mir Deine Implementation gerade mal genauer angesehen und sehe jetzt klarer. Du ganze ist ein Websocket-server für den bestehenden io_smarthome.py.js treiber, richtig? Ich bin gerade genau den anderen Weg gegangen - generischer WebSocket-server im fhem + Javascript-library zur Adaption für die Gegenseite (http://forum.fhem.de/index.php/topic,29075.msg219069.html#new). Die library funktioniert schon soweit, dass man connecten, die komplette Config abholen, auf Events reagieren und readings per get/set manipulieren kann. Habe ich auch schon in einen irudimentären io_fhem.js-treiber gewrappt, allerdings noch ohne weitergehendes Mapping für Devices, die nicht ausschließlich über den state manipuliert werden. Da ist mir auch klar geworden, wozu Dein smartVisuEditor gut ist - irgendwie muss man ja die Ganzen Readings auf simple 'items' im smartVisu-kontext abbilden und das machst Du nicht über fhem-attribute, sondern legst es in einer separaten config-datei ab, richtig?

- Norbert

Hallo Norbert,

hatte Deinen anderen post auch gesehen, Stand aber den ganzen Tag unter Dauer Feuer und komme daher erst jetzt dazu.

Kurz: genau!  :)

Etwas detaillierter: ich verwende aktuell den domotiga treiber - der smarthome.py würde vmtl. genauso gehen.

Deswegen meinte ich auch das wir auf anwendungs Ebene wahrscheinlich keine Synergien fiinden, bei ws server selbst könnte das aber sein.

Das mapping/editor: richtig  :). sv bündelt in den widgets die grafische Darstellung, funktionell sind das aber zum Beispiel beim Thermostat 6 einzelne Buttons und zwei Anzeigen die erst einmal von konkreter Funktion (im Sinne von "ich bin ein Thermostat") losgelöst sind. Das macht auch Sinn, nach dem gleichen System funktioniert ja auch jeder HM Lichtschalter an der Wand. Damit jetzt der user nicht 2 Millionen notifys erstellen muss kapselt der editor die notifys plus Spezialfunktionen.

Technisch fragt sv nach dem laden per "monitor" die Liste der items (heissen dann gad) bei fhem an die es auf dem Display hat. svServer (zusammen mit svDevice) sendet dann initial den Zustand (per "item", übersetzt in das sv Format. Aus zB "on" wird "1") und aktualisiert (ebenfalls per "item") den Zustand wenn fhem passende Events erzeugt.

Der Nutzen, ich bleib beim Beispiel Thermostat: wenn ich zB von "comfort" auf "night" schalte muss ich ja sowohl in die readings als auch spezielle sets gehen, state reicht da nicht. Noch spezieller wird es wenn ich zB ein "at" oder eine "notify" auf "enable" oder "disable" setze, dann muss ich sogar in die attribute. Das wird eben komplett damit abgedeckt.

Dazu macht der Editor noch folgendes: ich lasse den ws port nicht für "alle" offen sondern ein device muss sich autorisieren. Im Augenblick per IP (was für ein internes Netz auch ok ist) später per certifikat. Der editor bestimmt also auch welches device welchen set lesen oder ändern darf. Plus special: erst pin eingeben dann darfst Du schalten. (Anwendung zB Alarmanlage auf Tab im Eingangsbereich).

Damit ich jetzt aber nicht für jedes device (iphone mama, papa, kind, oma  ::) tab hier, tab da...) das mapping jedesmal aufs neue erstellen muss liegt das mapping global in einer config, nur die berechtigungen muss ich per device vergeben.

Ansonsten gibt es noch "dialog" (zeige eine Meldung auf dem display), "trigger" (macht das gleiche wie fhem - trigger), "plot" und "log". Die sind noch tbd.

vg
jörg

Ich denke, das kann man durchaus gut verheiraten. Meine Anbindung kann mittlerweile das komplette fhem-remoting und ist dynamisch einfach um eigene Message-typen erweiterbar. Was noch fehlt ist ein Security-konzept (das sehe ich als unabhängig von smartVisu, es hat für mich - auch wenn ich es für produktiven Einsatz für unverzichtbar halte - zeitlich aber erst mal relativ niedrige Priorität) und eben das smartVisu-spezifische Mapping. Da hast Du ja schon einiges implementiert, das schaue ich mir jetzt mal ganz genau an. Wenn ich es richtig Verstanden habe soll es die Widgets (item in smartVisu) mit den zugehörigen fhem-readings beliebiger Devices (inklusive Mapping der Werte) zusammenbringen? Die Aggregationsebene darüber (z.B. 'Thermostat') ist dann doch nur ein 'optisches' Gruppieren (ggf. mit gemeinsamen Zugriffsrechten versehen) individuell gemappter Items, wobei die eigentliche Steuerungsfunktion in fhem verbleibt, richtig?

Übrigens: da meine Implementierung auf den TCPServerUtils basiert (ich bin ein Freund von Wiederverwendung) gabs das SSL 'für lau' dazu ;-)

Gruß,

Norbert

Dir ist schon klar das du bei deinem nächsten Post einen ausgeben musst ?  :D (1000)

Die Security ist nicht verhandelbar, wenn du die hinterher "ranbappst" wird das zu 99% flickschusterei. Aber die steht ja soweit auch n Framework, das zeit Argument entfällt also ;)

Das mit Widget gleich item stimmt so nicht. Ein Widget besteht meist aus mehreren items.

Du hast glaub ich jetzt Änderungen drin die ich noch kenne. (?) verstehe ich richtig, du ziehst quasi die fhem device komplett als Abbildung in das js. ?

Vg
Jörg

ich habe Widget mit Item synonym benutzt. Das ist im SmartVisu-kontext offensichtlich anders gemeint - also 'item'.

Die Security ist bei mir auch nicht verhandelbar, und das wird auch keine Flickschusterei, das ist aber (bzw. muss) ortogonal zu der übrigen Funktionalität des Frameworks (= websocket.pm + fhem.js) sein, damit es für alle Verwender einheitlich zur Verfügung steht. Daher kann sie weitestgehend unabhängig von dieser entwickelt werden.

Grundsätzlich stelle ich mir das so vor: Unmittelbar nach dem Connect wird js-seitig ein Callback aufgerufen, der Credentials abfragt, in einen Token verschlüsselt und mit jeder Message an den Server schickt. Messages ohne gültigen Token werden nicht akzeptiert. Security auf z.B. reading-ebene kommt dann 'on top', das wird plugable mit Callbacks vor ausführung des jeweiligen Commands auf der Serverseite realisiert.

im websocket.html, onConnected() (https://github.com/ntruchsess/fhem-mirror/blob/websockets/fhem/www/websocket.html#L20) rufe ich 'fhem.list()' auf, das sagt dem websocket-modul, dass es alle details der fhem-devices als 'listentry'-events schicken soll. Anschließend hat man die komplette fhem-konfig im js. Wenn man das Reading/Item-mapping in Attributen untergebracht hätte, wäre es also schon da ;-)
Damit kann man jedenfalls schon beim Connect alle items mit aktuellen Werten befüllen. (Auch an der Stelle kommt dann ein security-callback rein, der die Sichtbarkeit der Listentries regelt).

@Jörg: kurze Verständnisfrage: hat es einen besonderen Grund, warum du die 'webif-data'-requests aus smartVisuEditor.js über die get-methode abwickelst und nicht über den sowieso zur Verfügung stehenden Websocket?
Was hälst Du davon an dem Modul zu kooperieren (die Sache mit der Mapping-definition über den Editor gefällt mir recht gut das würde ich nicht noch mal schreiben wollen ;-)). Solange noch nichts released ist könntest Du z.B. meinen fhem-mirror clonen und Deine Changes dorthin committen, dann könnte man sich patches gegenseitig als 'pull-request' zukommen lassen bzw. sich einfach bei Bedarf per pull selber abholen (Ich hab schon mal einen branch 'smatVisu' mit deinem aktuellen Arbeitsstand (https://github.com/ntruchsess/fhem-mirror/commits/smartVisu) angelegt). Wenn Du nicht möchtest, dass Deine Dateien schon auf github liegen (Du hast noch keine Lizenz festgelegt, ich habe daher angenommen, dass so wie fhem selbst unter GPLv2 stehn soll), gib Bescheid, dann lösche ich den Branch wieder.

- Norbert

Hallo,

gibt es schon eine Version zum Testen?

Hi Norbert,

Zitathat es einen besonderen Grund, warum du die 'webif-data'-requests aus smartVisuEditor.js über die get-methode abwickelst und nicht über den sowieso zur Verfügung stehenden Websocket?

ja klar, Kapselung und Single-Responsibility-Prinzip. Der Editor ist Aufgabe in fhem web und sollte komplett darüber erfüllbar sein.

ZitatWas hälst Du davon an dem Modul zu kooperieren

Ja klar! Super gern! Das passt auch gerade wie arsch auf eimer (sorry), ich habe kommende Woche endlich wieder coding Zeit und milestone 1 (also items) ist schon lange überfällig.

Wir müssen uns aber auf eine gemeinsame Strategie einigen. Die Architektur ist ja in eine bestimmte Richtung angelegt. Ich würde Dir gern morgen mal zusammenschreiben wie (stand jetzt) der Plan ist. Ich erwarte natürlich nicht das Du Dich dann da drauf stürzt und anfängst die AP abzuarbeiten. Schau es Dir bitte mal an, schau wo Du evtl Einwände hast (die lass uns besprechen) und was Du mitträgst. Dann (nur so) können wir effizient arbeitsteilig in die gleiche Richtung arbeiten.

Passt das für Dich ?

vg
jörg

klar, passt.

Hi,

na denn.

geplanter (erster) Milestone ist das items bedient werden. "Von unten", also dem smartVisu Modul kommen ja dazu schon die "monitor" und die "item" auf das individuelle svDevice. Events von fhem kommen über die notify fn in das individuelle  svDevice. In beiden Fällen hast Du die Strukturen im code vmtl. schon erkkannt.

Geplant und in Teilen vorbereitet (fhem -> sv):
* in der notifyfn (vom svDevce) kommen device:reading an.
* die globale config ist so angelegt das die Struktur von device:reading auf @gad (liste weil durchaus geläufig das ein reading mehrere GAD bedient) in einen hash gelegt werden. Der hash gilt für alle svDevice und wird von smartVisu.pm verwaltet.

Wenn also ein event in fhem erzeugt wird prüft svDevice anhand @gad = $hash -> {device} -> {reading} ob (global) die Kombi device:reading für sv gebraucht wird. Wenn ja dann wird @gad gegen die aktuelle Monitorlist geprüft (also: wird das gad jetzt gerade benötigt / dargestellt).

Wenn ja wird das einzelne Gad aus der gadlist gegen die Berechtigungen geprüft.

Reihenfolge gesamt also: 1. kenne ich es, 2. benötige ich es aktuell, 3. Ich darf lesen||schreiben.

4.Wenn ja kommt der "converter" (siehst ja schon im editor). Prinzip converter: eine Menge perl sub mit definierten Aufruf und return.
Beispiel "on/off". Die perl sub (name vielleicht svcOnOff) bekommt das "on" von "oben" rein und schickt "1" raus. Das geht dann per "item" / Gad an smartVisu.pm (weil das die Verbindung verwaltet) und das schickt es an das Frontend. Die converter stelle ich mir so vor das der user den converter Namen in den Editor eingibt. Prinzip excel funktionen; die muss man wissen oder eben nachschlagen, je nach dem was ich von wo nach wo konvertieren möchte.

Die mitgelieferter Standard - converter sollen in einer *.pm liegen und von smartVisu.pm beim start eingebunden werden (und im Umfang je nach Bedarf wachsen). Außerdem hat der user die Möglichkeit, zB für homebrew device, sich bei Bedarf converter in die 99_myUtils zu schreiben. Dazu müssen nur das Naming und der Aufruf standardisiert sein, die eigentliche Konvertierung dürften in der Mehrzahl der Fälle Einzeiler sein. Das habe ich jetzt etwas vereinfacht beschrieben, tatsächlich muss der converter natürlich device, reading und einige andere parameter mit übergeben bekommen um spzialfälle handeln zu können.

Die Spezialfälle werden eintreten, ein Beispiel welches mir jetzt schon klar ist, sind zum Beispiel RGB Device. In Richtung sv->fhem ist das so gelöst das jeder Channel ein eigenes GAD ist. Wenn man jetzt ein widget hat wo zum Beispiel 3 einzelne slider (rgb) sind dann ist das auch ok. Bei Farbwahlfelder oder dem Farbrad ist das jedoch doof weil die Lampen dann flackern (weil erst r, dann g dann b nacheinander gesetzt werden).

Für rgb device werden drei converter (einer pro channel) benötigt und sowohl r und g müssten sinnvollerweise puffern während b dann den Wert zusammensetzt und auf das device bringt. Dazu muss der den context kennen (also die beiden anderen zugehörigen converter). Ebenfalls keine Raketenwissenschaft aber Erklärung der "weiteren Paramter" die eben eingeplant sein müssen.

Der genrelle Weg sv-> fhem sogar noch einfacher: "monitor" setzt die gleichnamige Liste (im svDevice. is ja schon drin), im Anschluss müssen die einzelnen GADs der List noch ein mal initial (Schritt 4 oben) ausgelöst werden. Wenn das sv Frontend Aktionen per item auslöst: converter und dann den (editor) set Befehl.

Ich glaube der post ist jetzt schon länger als der code den er beschreibt, mir gehts darum möglichst viel zum geplanten funktionsverständniß beitragen zu können.

An diesem Punkt wäre dann milestone 1 erreicht, fhem erkennt und verwaltet unterschiedliche svdevice und kann sie beliefern bzw führt die Aktionen aus.

Das smartVisu frontend erkennt unterschiedliche device allerdings noch nicht, dort muss man manuell das entsprechende Unterverzeichnisse ansurfen. Diese Unterscheidung soll jedoch stattfinden. Außerdem fehlt Verschlüsselung und client certifiakte. In smartVisu.pm ist das vorbereitet. "startWSServer" muss einmal dupliziert werden nach "startWWSServer", genauso einfach wie Du das für TCPUtils beschrieben hast wird dort ein ssl sock gestartet und mit den certifiakten versorgt. Ursprünglich habe ich mal darüber nachgedacht die Zertifikate dann auf den sv host zu kopieren und dort den entsprechenden Server (Apache, nginx whatever) zu konfigurieren und in die index.php eine Weiche (für das client certifikat einzubauen). Allerdings halte ich es für sehr erstrebenswert an smartVisu möglichst wenig (nichts) zu ändern. SmartVisu wird von einem eigenen Team weiterentwickelt mit denen ich nichts zu tun habe, die haben eine eigene Roadmap und jede eigene Änderung an sv ist riskant weil man nie weiß ob die nach evtl. Updates noch funktioniert. Man müsste außerdem dann neu patchen, testen etc. Kurz: doof.

Ich denke das ich ein viel besseres System (sowohl für den user, Einfachkeit der Bedienung, als auch im Hinblick auf sv updates) gefunden habe: smartVisu.pm bekommt einen einfachen reverse proxy (tls, die Zertifikate hat fhem ja sowieso). Der muss ja nix tun als einen Port aufzumachen, die Verbungen nach per accept zu bedienen, das cert des clients zu prüfen, (entschlüsseln macht der sock selber) und dann seinerseits vom svhost die Daten per hhtprequest aus dem richtigen Verzeichniss zu holen). Verständlich ? Damit entfällt alles patchen, das Zertifikat braucht nicht doppelt vorgehalten werden etc, und die lines auf code sind auch nicht mehr gegenüber dem patchen der index.php mit weiche usw. (da müsste der client test etc ja genauso implementiert werden)

Zu diesem Zeitpunkt wäre dann die Sicherheit auch nach aktuellen Fachstand gewährleistet. Der client validiert den host (per cert). Die Verbindung ist Verschlüsselt. Der client wird per cert identifiziert. Für Zugriff benötigt man Besitz (mobile mit cert) und Wissen (pin des mobile).

Danach würde dann die Integration von Dirks webViewControl sowei plots und log dransein.

Einwände, Ideen, Anmerkungen, Befürchtungen ?

vg
Jörg

@herrmannj

Wäre die Reihenfolge nicht besser?
1. Ich darf lesen||schreiben.
2. Kenne ich es
3. Benötige ich es aktuell

Weil wenn er eh nicht lesen||schreiben darf, verwirken ja dann 2&3 und man "spart" sich die Schritte, oder liege ich falsch?

Hi,

Die Reihenfolge ergibt sich aus den notwendigen Schritten um aus device Reading das Gad zu identifizieren.

Vg
Jörg

Hallo, Jörg,

kannst Du etwas zu den Voraussetzungen der aktuellen Installation sagen?

Ich habe mit

cpan
force install warnings
install socket
install Fcntl
install POSIX
install Net::WebSocket::Server
install IO::Socket
install IO::Select
install JSON
exit


nachhelfen müssen, um den define erfolgreich durchzuführen.

Force install warnings war ein ziemliches Frage-Antwort-Spiel. Ich habe einfach alle defaults übernommen.

Fehlt sonst noch etwas? Ist z. B. Perl 5.20 Pflicht?

Gruß, Bernd

Hi,

eigentlich fällt mir nur  Net::WebSocket::Server und JSON ein.

da ich keine smartmatch mehr verwende sollte die perl version unkritisch sein. Aus user (nicht dev) Sicht siehst Du noch nicht viel. Die Autobahn sieht schon gut aus, in der Mitte fehlt noch eine Brücke  ;)

vg
jörg

Hallo Jörg,

Danke, das habe ich mir so im Großen und Ganzen schon so aus Deinem code zusammengereimt.

Mal meine Gedanken dazu (bitte nicht als falsche Kritik verstehen, ich betrachte das halt in einem etwas größeren Kontext)

Um eine Insellösung zu vermeiden sollte man die Themen Berechtigungsprüfung, Mapping und Konvertierung unabhängig von SmartVisu als generischen Mechanismus relativ nahe am FHEM-kern implementieren. Wenn es richtig gemacht ist, könnte man den eventMap-mechanismus endlich mal durch was vernünftiges ersetzen. Da hätte auch FHEMWeb oder das MQTT-modul etwas davon und die Benutzer müssen nicht für jede Schnittstelle bzw. Frontend eine neue Lösung lernen. Spricht ja nichts dagegen, wenn das smartVisu-device für jedes GAD-device ein- oder mehrere Readings hätte, die so gemappt wären, dass sie die von den items erwarteten Werte enthalten. Das mapping von smartVisu-reading auf item wäre dann 1<->1 (und müsste bei passender Namenskonvention gar nicht weiter konfiguriert werden).

Das gleiche gilt für die Berechtigungsprüfung. Wenn man nur ein Frontend so absichert wird sich die überwiegende Mehrheit der User in Scheinsicherheit wiegen (weil das FHEMWeb-frontend und telnet per default laufen und nur rudimentär geschützt sind).
Wg. der Client-Zertificate: Da würde ich keine Arbeit reinstecken. Die meisten Benutzer werden das gar nicht einrichten wollen (oder auch können). Abgesehen davon ist das auf einem Enduser-gerät auch nur dann sicher, wenn das Zertifikat auch durch ein (weiteres) Passwort geschützt ist. (Und dann gehört das auch in den FHEM-kern - sonst ist sicherheitstechnisch nix gewonnen wenn die anderen Kanäle nicht genauso abgesichert sind). Eigentlich ist das nur was für Maschine<->Maschine Kommunikation (und auch da ist es prinzipiell auch nur dann sicherer als normales SSLv2 mit sicher abgelegten Credentials, wenn man beide Seiten validieren läßt, ob sie tatsächlich mit dem erwarteten Gegenüber verbunden sind, oder wenn man keine anderen trusted-root-Zertifikate als das eigene erlaubt).

Wenn man das so generisch lösen würde, wäre das eigentliche SmartVisu-modul sehr schlank. Als Nebeneffekt könnte man auch viel besser zusammenarbeiten: wenn man die zueinander orthogonalen Aspekte modular getrennt implementiert muss man sich nur einigen, wer was angeht und kommt sich dabei kaum in die Quere.

- Norbert

Hi,

ne, Danke, alles gut, seh ich nicht als Kritik  :) Ich biete ja gar keine Diskussion an wenn ich sie nicht will  ;)

ZitatUm eine Insellösung zu vermeiden sollte man die Themen Berechtigungsprüfung, Mapping und Konvertierung unabhängig von SmartVisu als generischen Mechanismus relativ nahe am FHEM-kern implementieren

Ja das wäre wünschenswert. Aber Ziele müssen realistisch sein. Ich sehe nicht das sich da eine Mehrheit, geschweige denn Umsetzung, findet. Die Eingriffe in den core wären gigantisch.

ZitatSpricht ja nichts dagegen, wenn das smartVisu-device für jedes GAD-device ein- oder mehrere Readings hätte, die so gemappt wären, dass sie die von den items erwarteten Werte enthalten.

Das verstehe ich nicht wie Du das meinst. Das mapping passiert doch, wozu die readings ?

ZitatWenn man nur ein Frontend so absichert wird sich die überwiegende Mehrheit der User in Scheinsicherheit wiegen.

Ne, das lass ich so nicht gelten. Der Umkehrschluss lautet ja fhemweb ist nicht abgesichert, also lass ich das bei anderen Implementierungen auch weg. Richtig sollte sein: smartVisu wird fachlich korrekt gesichert. Ich verantworte den smartVisu Treiber, nicht fhemweb. Ob man dann fhemweb über das Netz zugänglich  macht oder nicht darf (und muss) jeder selbst entscheiden, jeder für sich.

ZitatClient-Zertificate: ... Die meisten Benutzer werden das gar nicht einrichten wollen (oder auch können).

Lass Dich überraschen, alle aktuellen Device/browser haben den support dafür alle eingebaut. Das ist viel einfacher als Du denkst. Das cert wird über das interface des svDevice erstellt, der browser fragt Dich ob er das importieren soll (die haben ein Art safe dafür drin) fertig  ;)

Sag nochmal bitte welche Zuständigkeiten und Verantwortungen Du in welchem Modul (oder Teil) siehst, vielleicht verstehe ich Dich dann besser. Ich habe noch nicht verstanden welche Änderungen Du konkret vorschlägst. (sorry, my fault)

vg
Jörg

Hi Norbert,

post#2,

Wahrscheinlich ist es hilfreich nochmal genau zu spezifizieren was wir "noch alles" damit bedienen wollen.

Also, reden wir über hypothetische, zukünftige Frontends ? Wer genau soll auf den websocket noch zugreifen ? Welche Daten würden benötigt ?

vg
Jörg

Das mit den Readings meine ich so: basierend auf der Mapping und Konvertierungskonfiguration sollen in einem (konfigurierbaren) Device (bidirektional) Readings erzeugt bzw. aktualisiert werden. Das Reading kann dann z.B. so wie das SmartVisu-item heißen (ggf. auch mit einem Präfix). Der Wert des Readings kann dann vom SmartVisu-treiber ohne weitere Umwandlung direkt an das item geschickt werden. Durch die Abbildung auf Readings wären die Mapping und Konvertierungsfunktionen aber auch für andere Frontends und/oder Devices nutzbar, das wäre dann sowas wie ein deutlich leistungsfähigeres readingsProxy oder readingsGroup-device. Der Mehraufwand bei der Implementierung gegenüber einer in den smartVisu-treiber integrierten Lösung wäre sehr gering, der Nutzen durch die mögliche Wiederverwendbarkeit hoch.

Beim Zugriff auf Websocket denke ich nicht nur an reine Frontends. Es gibt da z.B. auch leistungsfähige Middleware auf Node.js (z.B. NodeRed). Natürlich würde das FHEM in die Nähe eines reinen Hardwaretreibers rücken - für Leute, die schon mit einer anderen Lösung arbeiten und nur ein paar (in FHEM verfügbare) Devices integrieren wollen, würde das aber Sinn machen.

Und wegen der Security und 'im Core' - da stelle ich mir jetzt nicht vor, dass plötzlich alles irgendwie hart abgesichert sein soll (da fehlen Perl selbst die notwendigen Funktionen für), wenn die Frage 'darf jemand und wenn ja, auf welchem Level (lesend/schreibend/konfigurierend) auf ein Device oder Reading zugreifen' aber übergreifend über eine (von Frontends und remote-schnittstellen) nutzbare API überhaupt erst mal abfragbar wäre, dann könnte man so eine Prüfung leicht in weitere relevante Module einbauen auch ohne dass dafür zwingend der SmartVisu-trieber laufen müsste.

Wahrscheinlich liegst an mir, aber so richtig schlauer bin ich jetzt nicht.  ;)

Die Funktionalität, so wie du sie beschreibst, ist ja im großen und ganzen so wie sie auch geplant ist. Das readingsproxy device das du beschreibst ist doch das svdevice ?

Ich denke die Schwierigkeit besteht darin jetzt da irgendwelche hypothetischen Frontend gedanklich reinzumischen deren Anforderungen ja eigentlich gar keiner kennt oder benennen kann. Das ist doch wie bei jedem anderen fhem device auch, wenn ich homematic bedienen will muss ich mir anschauen was brauch ich, was wird geliefert, wie verbinde ich das sinnvoll. Jetzt irgendwie zu versuchen ein fhem device zu bauen um dann alle zukünftigen rf Schalter zu bedienen wird nicht funktionieren.

Zu den hypothetischen Frontend mal ganz klar, was spricht denn dagegen das die, wenn der Autor das wünscht (!), sich über die vs. Schnittstelle bedienen ? Da kommt doch alles raus was man braucht ? Und wenn dann im konkreten Fall was fehlt bin ich gerne bereit das dann einzubauen wenn es passt. Die Schnittstelle abstrahiert doch sowieso ...

Das gilt doch genauso für middleware. Die Schnittstelle bedient kein Design, nur Funktion. Ich kann dir aus dem Stegreif einen Schalter für die Wand da ransetzen. Der (hypothetische) wifi Schalter öffnet die Verbindung, sendet "Monitor" mit seinem Namen, das Modul schickt den Status zurück, der Schalter aktiviert seine led und heureka, es läuft. Alles ohne auch nur eine Zeile Code ändern zu müssen.

Wird vielleicht so ein Schuh draus ?

Vg
Jörg

na, Funktionell will ich im Großen und Ganzen schon in etwa auf das Gleiche raus. Nur so wie Du es planst und implementierst scheint es mir eher monolithisch als modular zu werden. Ein FHEM-modul, das ausschließlich über WebSocket-schnittstelle nutzbar ist, ist dann halt auch genau dafür gut. Wenn es dabei losgelöst von der Websocket-Schnittstelle einige (im Kontext FHEM) neue Konzepte implementiert, die aber innerhalb von FHEM nicht (bzw. nicht über saubere und dafür gedachte Interfaces) von anderen Modulen nutzbar sind, dann ist das halt monolithisch. Da habe ich auch keinen Schmerz damit, wenn Du das so implementieren willst, das wird schon funktionieren. Ich hätte Dir halt angeboten, Dich bei einer möglichen Modularisierung zu unterstützen.

Gruß,

Norbert

Hallo, Jörg,

ich habe jetzt die Voraussetzungen für das

define Test smartVisu

alle geschaffen, bekomme aber dennoch - ohne irgendein debug-output -

Cannot load module smartVisu

Kann's an der define syntax liegen? Ich werde da aus dem Code noch nicht sooo schlau.

Gruß, Bernd

Hi,

Die ist ja noch nicht gar, aber schau mal ins Log .

Denke mal die config fehlt

Vg
Jörg

Hallo, Joerg, ich würde gern erfahren, wie Du vorankommst und ob ich irgendwie helfen kann... Gruß, Bernd


Gesendet von meinem iPad mit Tapatalk

Hi Bernd,

nachdem ich wg Zeitmangel unterbrechen musste bin ich wieder dabei und es geht wieder planmäßig voran.

Gestern Nacht habe ich die "Verbindung" zwischen den fhem events und smartVisu hergestellt. Noch hardcodiert lassen sich die Bedienelemente auf der sv Oberfläche steuern. Next step sind jetzt die Konverter.

Dazu musste ich mich jetzt mal tiefer mit smartVisu beschäftigen. Im Prinzip klöppeln die ja mit php templates und jquery die Seiten zusammen. Wenn man etwas mehr möchte kann man recht fix (jquery verstehen vorrausgesetzt) eigene Sachen einbauen. Mri ist es aber auch ganz fix gelungen einen eigenen jquery poc ganz ohne sv da dran in Betrieb zu nehmen. Das Konzept ist damit definitiv für jeden der eigene Frontends an fhem hängen möchte hoch interessant. Von daher bin ich kurz davor das naming des Projektes in "fronthem" zu ändern um das zu unterstreichen.

Auf die roadmap und die funktion mit sv hat das keinen Einfluss, sind im Endspurt zur alpha  :)

vg
jörg

Klingt - wie immer - hochinteressant! Bin und bleibe gespannt! Siehst Du Synergien mit Hoanoho? Es wird an vielen Stellen an ähnlichen Zielen gearbeitet, aber wie auch hier schon zu lesen war, sind Vereinheitlichungen gar nicht so einfach...

ich schau natürlich nach links und rechts. Hoanoho hab ich mitgelesen, bin aber nicht in den details. Was ich gesehen habe ist das die Jungs das "Problem" haben konkrete device zu unterstützen wenn sie die nicht besitzen. sv ("fronthem" in spe) könnte das evtl lösen. Ob die das Nutzen möchten (und ob sie das integrieren können) weiß ich nicht, das Angebot an alle Frontends die Anbindung an fhem zu unterstützen spreche ich aber ganz explizit aus.

Ich mache erstmal mit sv weiter, wenn der erste wurf läuft kommt ja noch viel hinterher (Plots, certs, usw.) Irgendwann zwischendurch  8) mach ich mal eine kleine jquery vorlage damit die frontend jungs das Konzept nachvollziehen können. (geht jetzt auch, muss man halt mal schnell sv irgendwo draufziehen und dort in den source schauen)

vg
jörg

Guter Ansatz, Jörg! Ich finde es gut, dass Du so einen klaren Weg für Dein Projekt siehst und verfolgst! Gruß Bernd

Also großes Lob vorab an die Entwickler!

Ich habe smartvisu auch ins Auge gefasst und überlegt mir ein eigenes Modul dafür zu frickeln.

Meine Programmierkünste sind aber eher unterirdisch, so dass ich lieber auf euer Modul warte.

Freue mich schon auf die erste Testversion ;D

Gruß,
Thorsten

Liest jemand mit der sich mit smartVisu und fhem leidlich auskennt ? Ich hätte da eine frage, gerne per pm,

Danke und Grüße,
joerg

Hallo fhemfreunde,
ich wollte euch nur kurz mitteilen, das bgewehr einen Wiki-Beitrag angelegt hat, damit ihr euch schon mal ein wenig in die Funktion einlesen könnt.
Dieser wird mit der Zeit erweitert werden.

Viel Spaß damit: http://www.fhemwiki.de/wiki/Fronthem

Lg,
Tropaion

Das liest sich ja schon sehr ausgereift!

Weiter so

Moin,

ich habe das Thema als stiller Mitleser schon eine Weile verfolgt und mich nun angemeldet um mein Interesse zu bekunden.
Ich finden den Projektfortschrit jetzt schon bemerkenswert.
Sollte ich irgendwobei unterstützen können einfach bescheid sagen. Die Smart-Visu kenne ich ganz grob noch aus einem KNX-Testaufbau.

Beste Grüße,

TomTom

Hallo,

herrmannj hat eh gesagt das es nicht mehr lange dauern wird bis er die Beta veröffentlicht hat.
Du kannst dich ja schon mal im Wiki ( http://www.fhemwiki.de/wiki/Fronthem )einlesen, ich habe sie gestern schon stark ausgebaut (wird ständig erweitert).

Wenn du jedoch schon die Alpha testen und bei Fehlersuchen helfen willst (vorrausgesetzt du kennst dich gut mit HTML und FHEM aus) kannst du dich bei herrmannj melden, vll. nimmt er dich ja noch dazu.

Lg,
Tropaion

Was im Wiki-Artikel auf jeden Fall noch fehlt ist eine Installationsanleitung.

eins zwei Bilder vom Frontend wären auch nicht schlecht ;)

@dancatt, So weit für ein Installationsanleitung ist das Projekt noch nicht (aber ohne jetzt in Jörg reinschauen zu können)

@blackcat, wenn du mit Front-End smartvisu meinst, kann man es natürlich immer auf der Smartvisu Seite ansehen ;) für das FHEM-seitige Konfigurieren ist es wohl noch nicht so weit.

Zitat von: drdownload am 02 Dezember 2014, 13:50:23
So weit für ein Installationsanleitung ist das Projekt noch nicht (aber ohne jetzt in Jörg reinschauen zu können)

Und wie ist das mit den Alpha-Testern? Wo kriegen die eine Doku her wie was wann wo weshalb und warum installiert werden muss?

Die Alpha-Tester haben ja direkten Kontakt zu Jörg für Fragen etc.

@dancatt
Dieses Projekt ist eher für Leute gedacht die sich mit FHEM besser auskennen.
Diese brauchen eine Installationsanleitung nicht, wenn man sich auskennt, reicht die die im Wiki steht.
Ich arbeite gerade an einer ausführlicheren Anleitung, die jedoch noch sehr unübersichtlich ist.
Diese wird dann wahr als pdf im Wiki zum Download angeboten.

@blackcat
Im Wiki steht es auch, fronthem ist kein Webfrontend, sondern eine Schnittstelle um beliebige Frontends einfach an FHEM anbinden zu können. Jedoch testen und arbeiten wir mit SmartVisu, www.smartvisu.de
Und wir werden auch auf Basis von SmartVisu die Funktion erklären.

@drdownload
Die Anbindung an FHEM der SmartVisu funktioniert schon so gut wie ohne Probleme.
Ein paar kleine Fehler und Verbesserungen sind noch zu machen, wird nicht mehr lange dauern bis es in die Beta geht. Jedoch fehlen noch einige Funktionen, wie Zertifikate. Ich schaue das die Wiki täglich aktualisiert wird, und es ist auch nachzulesen, was schon läuft und was noch geplant ist.

@dancatt
Wir, die Alpha-Tester schreiben die Doku usw. ...und helfen herrmannj wo es nur geht.
Wir haben auch ständig E-Mailverkehr um auf Fehler aufmerksam zu machen, usw. ...

Lg,
Tropaion

Hi,

die alpha Tester sind da derzeit sehr aktiv (ganz herzlichen Dank dafür !!!) ,erarbeiten genau solche Anleitungen und betrieben Erfahrungssicherung für die Betatester.

Im Betatest können dann alle direkt von dieser Vorarbeit profitieren.

vg
jörg

Kleine Preview aus dem Alpha-Test:
(Basis ist fhem mit fronthem und SmartVisu auf einem BananaPi mit SSD, Homematic- und Intertechno-Komponenten plus Volkszaehler.org plus EMSCollector für die Buderus-Heizung)

Sieht verdammt gut aus!

Sieht ja schon ganz gut aus!  :)

Da freue ich mich schon auf die Beta!

Sieht wirklich sehr ansprechend aus. Biete mich gerne als beta-Tester an.

schöne Grüße
Jo

bgewehr ist mir zuvor gekommen :D

@Jojo11
Also die Beta wird vermutlich eh öffentlich sein, brauchst dich nicht anmelden :)

Das schaut super aus. Gibt es schon einen groben Zeitplan für die Beta?

Genaueres hat herrmannj noch nicht dazu bekannt gegeben.
Jedoch meinte er, das es nicht mehr sehr lange dauern würde^^
Vll. äußert er sich ja selbst dazu ;)

Lg,
Tropaion

Gibt es schon neues vom Modul fronthem?

Nebenbei zum Thema smartVISU - gibt es irgendwo eine Einführung wie man smartVISU verwendet?
So etwas in der Art, wie die Einsteiger PDF für fhem oder ein gutes Forum, welches sich mit smartVisu beschäfigt?
Alles was ich gefunden habe, war nicht sonderlich informativ oder auf einem passwortgeschützten FTP-Server.

Beste Grüße
Fabian

Schau noch mal hier: http://forum.fhem.de/index.php?topic=27291.msg208880#msg208880

Soweit die Installation. Die Verwendung ist so: man editiert die Seiten im eigenen Ordner im Ordner Pages und fügt dort Dinge ein, die man aus der Doku z. b. auf SmartVISU.de rauskopiert. Auch die Beispielhäuser sind sehr hilfreich beim lernen...

Einen speziellen Editor oder eine grafische Oberfläche für die Programmierung gibt es nicht.

Klingt erst mal blöd, ist aber nach 2 Tagen Fummelei kein Problem mehr...

Hier noch mal mein

Protokoll des ersten Tages:
-----------------------------------

Datei-Installation:
===============
Dateien 01_frontfhem.pm, 31_frontfhemDevice.pm und fhconverter.pm in das ../fhem/FHEM/ Verzeichnis kopiert, chmod 777 (muss man sicher nicht, aber was wäre empfehlenswert??)
Datei fronthemEditor.js in ../fhem/www/pgm2/ kopiert
chmod 777 (...??)

PERL:
=====
Auf der Kommandozeile die benötigten Perl Module installieren oder prüfen:

cpan strict
cpan warnings
cpan JSON
cpan URI::Escape
cpan Time::HiRes
cpan Data::Dumper
cpan Socket
cpan Fcntl
cpan POSIX
cpan IO::Socket
cpan IO::Select
cpan Net::WebSocket::Server


smartVISU:
=========
- Grundinstallation:
Ich habe jetzt lighttpd und Raspian verwendet:

sudo apt-get update
sudo apt-get install lighttpd
sudo apt-get install php5-common php5-cgi php5
cd /var/www
sudo lighty-enable-mod fastcgi-php
sudo service lighttpd force-reload
sudo chown www-data:www-data /var/www
sudo chmod 775 /var/www
sudo usermod -a -G www-data pi
sudo usermod -a -G www-data bananapi
sudo wget http://smartvisu.de/download/smartVISU_2.7.zip
sudo unzip smartVISU_2.7.zip
sudo rm smartVISU_2.7.zip
sudo chmod 777 smartVISU
cd smartVISU
sudo chmod 777 temp

Im Browser http://<DeineIP>/SmartVISU

Läuft!

- im Ordner /var/www/smartVISU/pages neuen Ordner MeinHaus angelegt
- aus dem Ordner ../pages/_template alles in den neuen Ordner kopiert
- rooms_menu.html an mein Gebäude angepasst
- alle rooms angelegt als Kopie des Beispielraumes und passende icons und Überschriften verteilt
- SmartVISU Seiten bestehen aus Blöcken und Widgets, die immer in doppelten geschweiften Klammern stehen {{ ... }}
- Widget Syntax aus SmartVISU Doku aus SmartVISU.de nachgeschlagen und kopiert
- innerhalb eines Raums zwischen {% block content %} und {% endblock %} als Beispiel folgenden Abschnitt eingefügt:

<h1><img class="icon" src='{{ icon0 }}scene_livingroom.png'/>Wohnzimmer</h1>
    <div class="preblock">
    </div>
    <div class="block">
        <div class="set-2" data-role="collapsible-set" data-theme="c" data-content-theme="a" data-mini="true">
             <div data-role="collapsible" data-collapsed="false" >
                <h3>Licht</h3>
               <table width="90%">
                   <tr><td align="left" width="100px">&nbsp;
{{ basic.switch('Leselampe', 'Leselampe.sw', icon1~'light_floor_lamp.png', icon0~'light_floor_lamp.png') }}
</td><td>Leselampe</td></tr>
              </table>
           </div>
        </div>
    </div>

- Datei gespeichert und Rechte mindestens chmod 755
- smartVISU aufgerufen, eigenes Haus ausgewählt (Ordnername!) und als Treiber DOMOTIGA mit Port 2121 mit der IP des FHEM-Servers oder domotiga.local, wenn auf demselben Gerät auch fhem läuft
- speichern der Config nicht vergessen (Save ganz unten!)

FHEM:
=====
- fronthem device angelegt
define fronthem fronthem
- Meine Endgeräte (Handy, Tablet) als fronthemDevice angelegt mit Geräte IP-Adresse (zum nachschlagen am Endgerät die IP prüfen oder in der FritzBox nachsehen)
define Handy fronthemDevice 192.168.178.34
- device Details von Handy öffnen
- aus der itemlist ein smartVISU item ausgewählt (hier: Leselampe.sw, Name ist frei vergebener Text) und die Parameter vergeben:
    device: fhem-Name des fhem-devices (bei mir die Leselampe.sw)
    reading: state
    converter: OnOff
    cmd set: state
    write: ja
    read: ja
    "state" immer klein schreiben und speichern nicht vergessen!
Die Settings für das Device gelten für alle Endgeräte, aber die read/write Rechte müssen für jedes Endgerät separat gesetzt werden.

Ich hab mir noch n Tannenbaum eingebaut (ist ja bald...) und das Icon der Lampen geändert. dazu einfach aus dem  Ordner /var/www/smartvisu/icons/sw das passende Icon aussuchen und dann in den {{ ... }} als Bildernamen z. B.  'scene_x-mas.png' anstelle der oben verwendeten Bilder verwenden.

fertig (für's erste!)!

Hallo,

wo bekomme ich denn die Module zum testen her? (01_frontfhem.pm etc...)

Habe ich leider in keinen Thread oder Update gefunden.

Grüße

Grav

Hermannj wird den Public Beta Test bald eröffnen...

Dann sind die freien Tage ja gerettet:-)

Das wäre wirklich ein perfektes timing :) Macht es eigentlich Sinn, smartvisu auf einem eigenen (z.B.) Raspberry zu installieren, auf dem nicht fhem läuft?

schöne Grüße
Jo

Ich habe alles auf einem bananaPI installiert - läuft super!

@Jojo11
Hab ich bei meinem RasPi auch überlegt, aber derzeit läuft es ohne Probleme.
Du kannst es ja zuerst auf einem probieren und wenn es nicht gut läuft nimmst du einen 2ten dazu, ist ja nicht so das Problem^^

Lg,
Tropaion

Ok, danke. Wollte ohnehin demnächst mal auf eine etwas leistungsstärkere Hardware umsteigen.

schöne Grüße
Jo

odroid .... rennt  auch 8)

So smartvisu läuft zum test :) also her damit :P

ich modifiziere gerade sv so das es die device unterschieden werden (mandantenfähigkeit).

Die beta möchte ich noch vor Weihnachten starten damit ihr über die Feiertage nicht hilflos der Schwiegermutter ausgeliefert seid  ;)
Es gibt noch viel zu tun, plots und zertifikate stehen für spätere Versionen auf todo.

vg
jörg

Gibt es schon Neuigkeiten?

Hallo tomtom (hallo @all),

sv ist modifiziert, erste bugs beseitigt. Wir wollen bis Mi eine erste Version reinstellen, damit das warten eine Ende hat und die Test beginnen können.

Bin mir jetzt noch nicht sicher ob man schon bbeta dranschreibt, denke Entwickler preview triffts auch. Obwohl bisher nur ein kleiner Teil der Funktionalität drin ist kann man schon erstaunlich viel damit anstellen. Meine Angst ist eher das user ohne den notwendigen background (fhem, html, js) sich dann daran versuchen und scheitern (Frust schieben). Aktuell wird, wer damit startet, sich auch einiges alleine erarbeiten müssen es gar keine doku in grosser runde gibt (geben kann).

Außerdem werden (da bin ich mir sicher) auch bugs auftreten, (weil projekt ist jung) - aber geht ja weiter.

vg
jörg

Wenn ich dazu komme, habe jetzt eh Ferien, schaue ich mal ob ich vll etwas zusammenstellen kann das ein wenig hilft, werde mich noch mit herrmannj und denn anderen Testern absprechen

Lg,
Tropaion

Hi Tropaion,

naja, für die reine Installation habt ihr ja gut vorgearbeitet (Danke) - da müssten jetzt noch die neuen sv Dateien rein. So die generelle "sv Denke" (so nenne ich das jetzt mal), da muss man sich das selbst rein arbeiten ...

Ich hab jetzt auch angefangen einzurichten, hab im wiki angefangen (erstmal eins  :)) unter smartvisu rein zuschreiben. (icons markiert in menus).
Hab quasi unter smartvisu/... einen eigenes dir angefangen. Vielleicht hast Du (ihr) ja auch noch einiges, bgewehr hat mit den HM rtr ja auch viel erarbeitet. Ansonsten wird das halt wachsen... Im Augenblick hält der ganze Vorweihnachtskram (sic) ja auch auf  ;)

vg
jörg

Hallo zusammen,

beta 1 ist hier erschienen:
http://forum.fhem.de/index.php/topic,30909.msg234616.html#msg234616

Ich schlage vor diesen thread damit zu beenden und evtl Fragen im thread der beta zu klären

vg
jörg

Hallo bgewehr,

wenn nicht bereits geschehen, finde ich sollte Dein Beitrag über die Installation von SmartVisu mit ins Wiki. Sonst geht der hier verloren ;-)

Gruß
Tino

Zitat von: bgewehr am 16 Dezember 2014, 06:50:06

PERL:
=====
Auf der Kommandozeile die benötigten Perl Module installieren oder prüfen:

Code Auswählen Erweitern


cpan strict
cpan warnings
cpan JSON
cpan URI::Escape
cpan Time::HiRes
cpan Data::Dumper
cpan Socket
cpan Fcntl
cpan POSIX
cpan IO::Socket
cpan IO::Select
cpan Net::WebSocket::Server


smartVISU:
=========
- Grundinstallation:
Ich habe jetzt lighttpd und Raspian verwendet:

Code Auswählen Erweitern


sudo apt-get update
sudo apt-get install lighttpd
sudo apt-get install php5-common php5-cgi php5
cd /var/www
sudo lighty-enable-mod fastcgi-php
sudo service lighttpd force-reload
sudo chown www-data:www-data /var/www
sudo chmod 775 /var/www
sudo usermod -a -G www-data pi
sudo usermod -a -G www-data bananapi
sudo wget http://smartvisu.de/download/smartVISU_2.7.zip
sudo unzip smartVISU_2.7.zip
sudo rm smartVISU_2.7.zip
sudo chmod 777 smartVISU
cd smartVISU
sudo chmod 777 temp

Im Browser http://<DeineIP>/SmartVISU

Läuft!

- im Ordner /var/www/smartVISU/pages neuen Ordner MeinHaus angelegt
- aus dem Ordner ../pages/_template alles in den neuen Ordner kopiert
- rooms_menu.html an mein Gebäude angepasst
- alle rooms angelegt als Kopie des Beispielraumes und passende icons und Überschriften verteilt
- SmartVISU Seiten bestehen aus Blöcken und Widgets, die immer in doppelten geschweiften Klammern stehen {{ ... }}
- Widget Syntax aus SmartVISU Doku aus SmartVISU.de nachgeschlagen und kopiert
- innerhalb eines Raums zwischen {% block content %} und {% endblock %} als Beispiel folgenden Abschnitt eingefügt:

Code Auswählen Erweitern


<h1><img class="icon" src='{{ icon0 }}scene_livingroom.png'/>Wohnzimmer</h1>
    <div class="preblock">
    </div>
    <div class="block">
        <div class="set-2" data-role="collapsible-set" data-theme="c" data-content-theme="a" data-mini="true">
             <div data-role="collapsible" data-collapsed="false" >
                <h3>Licht</h3>
               <table width="90%">
                   <tr><td align="left" width="100px">&nbsp;
{{ basic.switch('Leselampe', 'Leselampe.sw', icon1~'light_floor_lamp.png', icon0~'light_floor_lamp.png') }}
</td><td>Leselampe</td></tr>
              </table>
           </div>
        </div>
    </div>

- Datei gespeichert und Rechte mindestens chmod 755
- smartVISU aufgerufen, eigenes Haus ausgewählt (Ordnername!) und als Treiber DOMOTIGA mit Port 2121 mit der IP des FHEM-Servers oder domotiga.local, wenn auf demselben Gerät auch fhem läuft
- speichern der Config nicht vergessen (Save ganz unten!)

FHEM:
=====
- fronthem device angelegt

Code Auswählen Erweitern

define fronthem fronthem
- Meine Endgeräte (Handy, Tablet) als fronthemDevice angelegt mit Geräte IP-Adresse (zum nachschlagen am Endgerät die IP prüfen oder in der FritzBox nachsehen)

Code Auswählen Erweitern

define Handy fronthemDevice 192.168.178.34
- device Details von Handy öffnen
- aus der itemlist ein smartVISU item ausgewählt (hier: Leselampe.sw, Name ist frei vergebener Text) und die Parameter vergeben:
    device: fhem-Name des fhem-devices (bei mir die Leselampe.sw)
    reading: state
    converter: OnOff
    cmd set: state
    write: ja
    read: ja
    "state" immer klein schreiben und speichern nicht vergessen!
Die Settings für das Device gelten für alle Endgeräte, aber die read/write Rechte müssen für jedes Endgerät separat gesetzt werden.

Ich hab mir noch n Tannenbaum eingebaut (ist ja bald...) und das Icon der Lampen geändert. dazu einfach aus dem  Ordner /var/www/smartvisu/icons/sw das passende Icon aussuchen und dann in den {{ ... }} als Bildernamen z. B.  'scene_x-mas.png' anstelle der oben verwendeten Bilder verwenden.

fertig (für's erste!)!