Bei Auftreten v.Events div.Webseiten umschalten(Floorplan,Dashboard,etc)[gelöst]

[cocojambo]

Gut die Idee, Frank

Ich habe aus der Idee heraus jetzt was "zusammengebastelt" was zumindest funktioniert, auf Tab mit 5.11 und Firefox und FB, sieht so aus (nicht lachen)

Code Auswählen Erweitern

define Telefon_Anfruf notify Telefon_Test:on trigger WEBhome JS:location="/fhem/floorplan/Anruf"
attr Telefon_Anruf do always
define FritzBox1_notify notify FritzBox1:event.*ring trigger WEBhome JS:location="/fhem/floorplan/Anruf"

define FritzBox1_DOIF DOIF ([FritzBox1:event] eq "ring") (trigger WEBhome JS:location="/fhem/floorplan/Anruf")
attr FritzBox1_DOIF do always
attr FritzBox1_DOIF wait 5:0
#attr FritzBox_DOIF checkReadingEvent 1 

Die 5 sek merkt man nicht, denn FHEM hat das "ring" viel früher als mein erstes Telefon klingelt (hinter Fritzbox ist Telefonanlage dazwischen). Der Monitor ist etwas schneller als das TAB, aber bereits nach dem 2.klingeln schaltete es um. Habe es ein paar Mal probiert, auch aus verschiedeinen Unterordnern und Floorplänen, hat zu fast 100% funktioniert. Werde diese Version jetzt mal weiter mit ein paar Readings aus dem Callmonitor und ein bischen schöner auf den Anruf Floorplan bringen und mal weiter probieren.
Mal sehen..... sonst melde ich mich wieder, auch wenn´s weiter klappt.

Gruß
Norbert

[fiedel]

Sehr schön. Freue mich für dich! Ich kommentiere es mal um zu entwirren:

Code Auswählen Erweitern

define Telefon_Anfruf notify Telefon_Test:on trigger WEBhome JS:location="/fhem/floorplan/Anruf" # sollte weg können, weil "Telefon_Test:on" hier nirgendwo getriggert wird
attr Telefon_Anruf do always # kann weg, weil "Telefon_Anruf" kein DOIF ist
define FritzBox1_notify notify FritzBox1:event.*ring trigger WEBhome JS:location="/fhem/floorplan/Anruf" # ist wirksam weil "FritzBox1:event.*ring" aus deinem FRITZBOX- Modul heraus getriggert wird

# hier beginnt ein DOIF welches das gleiche tut wie das obige notify, nur mit etwas Verzögerung - damit kann quasi alles hier drüber weg, da das obige notify sonst sinnlos mitarbeitet
define FritzBox1_DOIF DOIF ([FritzBox1:event] eq "ring") (trigger WEBhome JS:location="/fhem/floorplan/Anruf")
attr FritzBox1_DOIF do always
attr FritzBox1_DOIF wait 5:0
#attr FritzBox_DOIF checkReadingEvent 1 


Gruß
Frank

[cocojambo]

Ja, habe ich mir schon gedacht, aber die ersten beiden Zeilen habe ich einfach drin gelassen, weil ich damit immer als Vergleich gucken konnte ob es über die FB noch geht. "do always" ist natürlich Quatsch, hat mich aber nicht gestört.
Die dritte Zeile ist noch aus der ersten Version und ist beim Kopieren für den Thread mit hereingeraten. Die hat da garnichts zu suchen und ist in meiner CFG auch nicht drin.
Die letzten 4 Zeilen sind die, die eigendlich nur wichtig sind. Die oberen waren nur zun Testen und werden garnicht gebraucht. Ich muß kein Anruf-Floorplan mit der FB einschalten.

Aber du kennst das ja sicher auch, als es plötzlich ging, habe ich sofort die Finger davon gelassen, Kopie von der FHEM.cfg gemacht, und erst mal alles getestet nach den Motto "never touch a running system".
Vorsichtige Frage: gibt es eigndlich bei FHEM sowas wie ein "Back-Funktion" um so wieder zum vorherigen Bildschirm zurückzukehren?

Meinst du es wäre sinnvoll, das ich rudolfkönig mal per PM oder in dem Thread, wo er diese Lösung vorgestellt hat, mitteile, das  es bei Verwendung des CALLMONITOR noch einen kleinen Bug gibt. Vielleicht interessiert ihn das und hat dazu eine Lösung, auch wenns so bei mir funktioniert?

Gruß
Norbert

[fiedel]

Aber du kennst das ja sicher auch, als es plötzlich ging, habe ich sofort die Finger davon gelassen, Kopie von der FHEM.cfg gemacht, und erst mal alles getestet nach den Motto "never touch a running system".
Vorsichtige Frage: gibt es eigndlich bei FHEM sowas wie ein "Back-Funktion" um so wieder zum vorherigen Bildschirm zurückzukehren?

Meinst du es wäre sinnvoll, das ich rudolfkönig mal per PM oder in dem Thread, wo er diese Lösung vorgestellt hat, mitteile, das  es bei Verwendung des CALLMONITOR noch einen kleinen Bug gibt. Vielleicht interessiert ihn das und hat dazu eine Lösung, auch wenns so bei mir funktioniert?

Na klar kenne ich das.  Für "Back" nutze ich nur den Zurück- Button des Browsers. Wenn es den nicht gibt, müsste man sich Weblinks bauen und im z.B. im Floorplan platzieren:

Code Auswählen Erweitern

# Button Haupt- FP zu öffnen:
define Main weblink htmlCode <a onClick="window.open "href="/fhem/floorplan/0_Hauptbildschirm"><img src="/fhem/icons/Button_DOE" width="100" height="100" border="0" alt="Home"></a>
attr Main fp_1_Untergeschoss 33,213,0,
attr Main fp_2_Obergeschoss 33,213,0,
attr Main fp_3_Garten 316,236,0,
attr Main fp_4_Plots_Heizung 33,213,0,
attr Main fp_5_Plots_Sicherheit 33,213,0,
attr Main fp_6_Plots_Klima 33,213,0,
attr Main fp_7_Plots_Energie 33,213,0,
attr Main group Weblink_Buttons
attr Main room 5_System

Bei der Telefon- Anzeige- Funktion habe ich noch ein zweites Notify auf ".event:.disconnect", was mir den Bildschirm wieder auf den Startfloorplan zurückholt, wenn aufgelegt wurde.

Weil das ja nun doch schon etwas umfangreicher hier ist, habe ich mal selbst getestet: Bei mir geht die neue Variante aus der Eingabezeile heraus und auch aus dem Notify auf "ring" einwandfrei mit Firefox und Chrome (ohne Verzögerungszeit). 
Muss also doch bei dir was faul sein. Das wird ja dann wohl am Server liegen: Triggerst du noch andere Sachen auf "ring" von der FB?
Wenn ja, bitte die erst mal deaktivieren. Oder auch anderes, was als notify oder DOIF an der FB hängt.
Ein Fall für den Thread der Umschaltfunktion ist dass dann wohl vorerst nicht.

Gruß
Frank

[cocojambo]

Das einzige was bei mir noch in Verbindung mit der FritzBox1 Abfrage läuft ist der CALLMONITOR, CALLIST und ein notify der beiden FB Box ABs über "internal_connection". Eine "ring" Abfrage läuft nicht zusätzlich.
Wenn ich es ohne die 5 sek versuche, geht es nicht aus den TABs des Dashboards heraus. Dann schaltet FHEM nur zufällig mal um, mit 5 Sek geht zuverlässig immer, aus jedem Verzeichniss. Ohne "ring" Abfrage gehts auch im TAB und auch bei Firefox über die Test-FB und Kommandozeileneingabe.

[fiedel]

Habe es gerade noch mal mit Dashboard probiert: Auch da sofortiges sicheres umschalten auf die Anrufer- Floorplanseite. Hm, also du kannst es ja so lassen wenn es für dich o.k. ist, oder du betreibst Ursachenforschung.

Dazu würde ich z.B. den Inhalt des FHEM- Ordners (/opt) sichern und dann neu installieren, oder ein frisch heruntergeladenes FHEM dort hinkopieren. Dann dort nach und nach dein System aus der Sicherung dort wieder aufbauen und dabei immer testen, ab wann die Verzögerung auftritt. Ein zweiter Minirechner mit Testsystem macht sich für sowas immer gut.

[cocojambo]

Hallo Frank,

danke für deinen Ratschlag, aber ich muß dir sagen, ich bin froh, das ich das nicht gemacht habe, und stattdessen weiter gesucht habe.
Der Fehler mit der Verzögerung macht die FB_CALLLIST. Wenn ich die komplett rausnehme geht es wie du gesagt hast, direkt beim ersten Klingeln und aus jedem Unterordner des Dashboards.

Code Auswählen Erweitern

define Anrufliste FB_CALLLIST FritzBox1
attr Anrufliste create-readings 1
attr Anrufliste event-on-change-reading .*
attr Anrufliste group Anrufliste
attr Anrufliste language de
attr Anrufliste number-of-calls 100
Und zwar tritt die Verzögerung immer deutlicher auf, wenn die Anzahl der anzuzeigenden Anrufe größer wird. Lösche ich die Anrufliste, funktioniert es einwandfrei. Sind die ersten 20-30 Anrufe drin geht es nur noch zeitweise und bei 100 dann nur noch mit der eingebauten Verzögering im DOIF.
Jetzt stellt sich mir die Frage warum? Werden die 100 Anrufe jedesmal neu eingelesen oder was soll sonst die Verzögerung ausmachen. Die 100 Anrufe sind doch gespeichert und es muß doch nur der Neue dazu und unten einer "weg" genommen werden.

Wie kann man jetzt erreichen, das die FB_CALLLIST nicht mehr die direkte Anrufanzeige verzögert?

Gruß
Norbert

[fiedel]

Hi Norbert,
das klingt doch schon mal gut. Meine Callist ist z.B. nur 5 Einträge groß. Es muss ja jeder Eintrag um 1 Zeile weitergeschoben werden und das kostet vermutlich bei vielen Einträgen viel Zeit. Du könntest nun die Liste auf z.B. 10 Einträge verkleinern, oder mal den Developer der Callist fragen, ob man da noch was machen kann.

Gruß
Frank

[cocojambo]

Ich habe Markus Bloch mal per PM angeschrieben. Mal sehen was er meint.
Gruß
Norbert

[Markus Bloch]

Hallo Norbert,

hier hast du Dein Problem versteckt. Bin durch Zufall drauf gestoßen.

Zu deinem Problem: Aktuell wird bei jedem Event die gesamte Liste aktualisiert. Das bedeutet für jede Zeile wird ein spezielles Event direkt an entsprechende Web-Clients geschickt, die eine FB_CALLLIST gerade geöffnet haben. Bei 100 Einträgen sind das also 100 Events um jede einzelne Zeile neu zu ändern. Dazu kommen noch über 600 Events, wenn man "create-readings" aktiviert hat, da für jedes Reading ein einzelnen Event erzeugt wird.

Ich habe mal FB_CALLLIST intern umgebaut um eben nicht immer die gesamte Liste zu aktualisieren, sondern nur den betreffenden Eintrag (einzelne Zeile) zu ändern. Es wird bei einem Anrufevent nun nur noch ein einzelnes Event gefeuert um den jeweiligen Eintrag in der Liste hinzuzufügen/aktualisieren/löschen. Da die Änderungen doch sehr gravierend waren, ist es durchaus möglich, das ich nicht alles bedacht habe.

Bei Readings werden natürlich nachwievor alle Readings mit einem Event getriggert, da hier die Werte wirklich zum nächsten Reading wandern müssen. Bei 100 Einträgen würde ich generell emfpehlen auf Readings zu verzichten, da dies einen enormen Overhead für die Event-Maschinerie darstellt.

Viele Grüße

Markus

Die Änderungen gibts ab morgen.

[cocojambo]

Hallo Markus,

habe gerade ein Update gemacht und werde mal beobachten was passiert wenn sich so langsam die Liste bis 100 gefüllt hat.
Was aber auch eine Möglichkeit wäre, das man die FB_CALLLIST einfach nach Eingang des Anruf zeitverzögert ausführt. Dann wäre das Problem doch auch gelöst, oder?

Gruß aus Köln
Norbert

[cocojambo]

Hallo Markus
Die Änderung der Calllist funktioniert bei eingehenden Anrufen zuverlässig immer, bei ausgehenden Anrufen fast immer (>90%), aber das Problem ist auf jeden Fall mit der Änderung gelöst und ich habe auch sonst keine Fehler bemerkt.

Gruß
Norbert