mit dem angehängten patch werden die globalen events für ATTR, DEFINED, DELETED, ... auch per longpoll weiter gegeben.
das global device wird hierzu automatisch in die liste der inform devices eingefügt.
hintergrund: ich baue gerade in dem homebridge shim ein das neue devices und änderungen an der konfiguration automatisch erkannt werden ohne das man hierzu komponenten neu starten muss.
ich könnte mir vorstellen das das auch für andere frontends interessant ist.
damit könnte man auch fhemweb so umbauen das das SAVE auf js seite erkannt wird um das ? rot zu machen statt den js code ans frontend zu schicken.
Was genau soll das bringen, wenn man diese Events im FHEMWEB Frontend hat? Abgesehen vom roten Fragezeichen bei Save Config erschließt sich mir kein weiterer Use Case.
Gruß
Markus
fhemweb ist nicht das einzige frontend und es gibt noch andere clients die den longpoll mechanismus verwenden.
mein konkreter anwendungsfall ist gerade der homebridge shim für die siri integration. hier ist es zur zeit nötig bei der änderung homebridge neu zu starten. mit der änderung tauchen neu angelegte devices einfach automatisch auf.
andere anwendungsfälle sind im frontend direkt anzeigen zu können ob ein device disabled wurde, auf änderungen von räumen oder gruppen zu reagieren ohne jedes im haus verteilte tablet anzufassen, ...
jedes frontend das die aktuelle konfiguration so genau wie möglich darstellen will sollte interesse daran haben mit zu bekommen das devices hinzugekommen oder verschwunden sind oder ob es andere änderungen an der konfiguration gegeben hat. neu einlesen der konfiguration von hand oder sogar neustarts sind altmodisch :).
gruss
andre
Zeichensetzung erleichtert Lesbarkeit.
Damit würde im Event-Monitor aber immer global-Events auftauchen, obwohl man vielleicht nur auf ein bestimmtes Device filtert, oder liege ich da falsch?
Ich finde es falsch, wenn man via inform nur bestimmte Devices bestellt und dann trotzdem global mit dazu bekommt. Ich würde es besser finden, wenn man global als Frontend explizit mitbestellt.
Gruß
Markus
mit dem event monitor hat das nichts zu tun. an dem ändert sich nichts. auch an inform ändert sich nichts.
es geht nur um fhemweb longpoll verbindungen.
im prinzip könnte man sagen das frontend muss die global events extra bestellen aber das problem mit dem explizit hinzufügen ist: manche frontends erlauben dem anwender den filter selber zu setzen. da der filter aber eine beliebig komplexe regex ist ist es nicht trivial bis fast unmöglich die regex automatisch um ein zusätzliches device zu erweitern.
zum anderen sind es im normalbetireb wirklich nur sehr wenige solche events.
gruss
andre
Zitat von: justme1968 am 17 Januar 2016, 17:01:46
im prinzip könnte man sagen das frontend muss die global events extra bestellen aber das problem mit dem explizit hinzufügen ist: manche frontends erlauben dem anwender den filter selber zu setzen. da der filter aber eine beliebig komplexe regex ist ist es nicht trivial bis fast unmöglich die regex automatisch um ein zusätzliches device zu erweitern.
wieso?
$old_regexp = "^device[ABC]";
$new_regexp = "(?:^global|$old_regexp)";
Würde doch funktionieren?
Zitat von: Markus Bloch am 17 Januar 2016, 16:54:44
Damit würde im Event-Monitor aber immer global-Events auftauchen, obwohl man vielleicht nur auf ein bestimmtes Device filtert, oder liege ich da falsch?
Ich finde es falsch, wenn man via inform nur bestimmte Devices bestellt und dann trotzdem global mit dazu bekommt. Ich würde es besser finden, wenn man global als Frontend explizit mitbestellt.
Gruß
Markus
Den use-case von Andre kann ich bestätigen. In fronthem/smartVisu benötige und nutze ich das. Damit kann man zb ber Button ein ein notify deaktivieren (disable) und wenn das von wo anders passiert zieht der button den status passend mit.
vg
joerg
Zitat von: herrmannj am 17 Januar 2016, 17:11:07
Damit kann man zb ber Button ein ein notify deaktivieren (disable)
Das mache ich im InfoPanel schon lange. Wobei ich da nicht das Attribut disable auf 1 setze, sondern per toggle umschalte:
attr <device> disable toggle Und im InfoPanel erscheint auf der "Schaltfläche" zusätzlich ein roter Punkt, wenn das notify enabled ist. Das funktioniert auch geräteübergreifend.
@Markus Bloch: regex war ungenau ausgedrückt.
der filter muss ein ausdruck sein den devspec2array versteht. also z.b. auch TYPE=HUEDevice oder room=homebridge. diese ausdrücke lassen sich aber nicht erweitern. unter anderem weil devspec2array schon etwas im prinzip einfaches wie TYPE=HUEDevice|NAME=global nicht mehr versteht.
die alternative wäre eine zweite longpoll verbindung aufzumachen die dann nur für global da ist. das braucht aber unterm strich mehr ressourcen als die handvoll global events.
gruss
andre
Zitat von: betateilchen am 17 Januar 2016, 17:31:17
Das mache ich im InfoPanel schon lange. Wobei ich da nicht das Attribut disable auf 1 setze, sondern per toggle umschalte: attr <device> disable toggle Und im InfoPanel erscheint auf der "Schaltfläche" zusätzlich ein roter Punkt, wenn das notify enabled ist. Das funktioniert auch geräteübergreifend.
ja. Aber fremde clients erfahren das nur nach page refresh oder liege ich da falsch
vg
joerg
Zitat von: herrmannj am 17 Januar 2016, 17:37:07
ja. Aber fremde clients erfahren das nur nach page refresh oder liege ich da falsch
Wenn ich das notify vom Laptop aus disable, wird es auf dem Tablet sofort (ok - mit der longpoll-üblichen minimalen Verzögerung) geändert.
das geht aber nur weil notify state auf disabled setzt und das ein readings ist über das du per longpoll informiert wirst.
wenn das setzen eines attributs keinen einfluss auf readings hat ist es per longpoill genau so unsichtbar wie alle anderen globalen events.
Ich fuehle mich unwohl beim Gedanken, jedem ungefragt die global Events zuzuschieben. Eigentlich vertrete ich die Meinung von Markus: wenn ein Client die Events sehen will, dann soll sie die bestellen. Ich sehe es aber ein, dass eine Erweiterung der devspec2array Parameter nicht trivial ist.
Vorschlag: der Client muss ein zusaetzliches Attribut "addglobal=1" beim Bestellen der longpolldaten (inform=...) setzen.
@Andre: verwendet "homebridge shim fuer siri" die von FHEMWEB generierte Seite/fhemweb.js, oder braucht sie nur die HTTP-Server-Faehigkeiten von FHEMWEB (habe keine Hintergedanken, nur als Info fuer mich :) ).
addglobal=1 beim bestellen per inform ist ok. die idee finde ich gut.
es wird nur die http fähigkeit verwendet. das ganze ist ein node js modul das initial per jsonlist den aktuellen zustand holt und dann per var query = "/fhem.pl?XHR=1"+
"&inform=type=status;filter="+filter+";since="+since+";fmt=JSON"+
"×tamp="+Date.now();auf alle updates lauscht.
Finde ich gut die Lösung.
Gruß
Markus
@rudi: ich kann gerade nicht testen aber wenn man im obigen patch statt $h{global} = 1; ein $h{global} = 1 if( $me->{inform}{addglobal} );verwendet sollte es damit doch erledigt sein?
Habs mit dieser Aenderung eingecheckt.