NEWS
ioBroker App 2023 [Android & iOS] - jetzt erhältlich
ioBroker App 2023 [Android & iOS] - jetzt erhältlich
-
@bommel_030 In Web Code ist es kein Problem die SSL Geschichten zu umgehen, aber WebView ist jeweils native Implementierung der mobilen Betriebssysteme.
Ja grundsätzlich ist mmn https lokal self signed i. O. , bin allerdings kein Security Experte

@foxriver76
1.0.15 installiert.Problem bleibt:
sobald man biometrie aktiviert friert die app manchmal ein -
@mrlee
Ich nutze ebenfalls Blockada 5 unter Android. Bei mir kommt dieser Hinweis nicht. Hilft es eventuell Visu unter Blockada als Ausnahme einzutragen? -
@foxriver76
1.0.15 installiert.Problem bleibt:
sobald man biometrie aktiviert friert die app manchmal ein -
Kannst du die alten Versionen hier in (z.B. unter #1) zur Verfügung stellen.
Oder macht man dies eher nicht (aus google play Gründen).
@bahnuhr sagte in ioBroker App 2023 [Android & iOS] - jetzt erhältlich:
Kannst du die alten Versionen hier in (z.B. unter #1) zur Verfügung stellen.
Oder macht man dies eher nicht (aus google play Gründen).
-
@bahnuhr sagte in ioBroker App 2023 [Android & iOS] - jetzt erhältlich:
Kannst du die alten Versionen hier in (z.B. unter #1) zur Verfügung stellen.
Oder macht man dies eher nicht (aus google play Gründen).
-
@dos1973 der reconnect sollte deutlich schneller sein als der Reload. Hintergrundaktuakiaierung + WebView wird vermutlich (soweit ich gelesen habe) nicht so gut zusammen passen. Falls jemand gegenteiliges weiß gerne melden.
Und dass der reconnect so old Style mit weißem Screen ist, ist vis selbst geschuldet.
@foxriver76 sagte in ioBroker App 2023 [Android & iOS] - jetzt erhältlich:
der reconnect sollte deutlich schneller sein als der Reload.
Das kann ich bestätigen, der reconnect erfolgt, sehe es an den Werten, dann aber kommt noch ein Reload.
-
@foxriver76 sagte in ioBroker App 2023 [Android & iOS] - jetzt erhältlich:
der reconnect sollte deutlich schneller sein als der Reload.
Das kann ich bestätigen, der reconnect erfolgt, sehe es an den Werten, dann aber kommt noch ein Reload.
-
@dos1973 meldet er auch dass er einen reload macht weil der reconnect gescheitert ist oder einfach so? Reload ist aus in den Settings?
@foxriver76
ich würde sagen einfach so, direkt im anschluss. geht recht fix.
ja das setting reload is aus.ich versuch mal ein screen shot - da kommt ja eine Info message
EDIT:
ja da steht Socket Reconnect fehlgeschlagen...
-
@foxriver76
ich würde sagen einfach so, direkt im anschluss. geht recht fix.
ja das setting reload is aus.ich versuch mal ein screen shot - da kommt ja eine Info message
EDIT:
ja da steht Socket Reconnect fehlgeschlagen...
-
@dos1973 aber sah erfolgreich aus? Dann muss ich das nochmal testen unter Android?
@foxriver76
Ja rein optisch würde ich behaupten er führt den socket Reconnect aus, die Vis Daten werden aktualisiert und dann gibt noch ein Vis Reload mit der weißen seitePassiert natürlich alles sehr fix.
Nur der Socket reconnect wäre das „Ding“


Btw. Vielen Dank für deine Mühe und Aufwand
-
@hiltex klingt nach aktualisiert vs geändert im Trigger. Du benötigst geändert.
@hiltex sagte in ioBroker App 2023 [Android & iOS] - jetzt erhältlich:
Eine Frage zu dem alive-State:
Wie kann man am besten darauf triggern?
Wenn ich auf „ist wahr“ triggere, dann wird der Trigger aller paar Sekunden ausgelöst.
Und andersherum: wie kann ich darauf triggern, dass er nicht wahr ist?Ich stehe gerade auf dem Schlauch
@foxriver76 sagte in ioBroker App 2023 [Android & iOS] - jetzt erhältlich:
@hiltex klingt nach aktualisiert vs geändert im Trigger. Du benötigst geändert.
Ich habe gerade nochmal ein bisschen herumprobiert. Kann sein, dass ich zuerst den Trigger auf aktualisieren gestellt habe und das der Grund war. Es ist jedoch nach wie vor so, dass man nicht auf "nicht wahr" triggern kann.
Ich habe folgendes Blockly dazu gebaut:

Bei alive == true löst das wunderbar aus, aber wenn das Tablet aus geht, dann reagiert das Blockly nicht.
Frage ich das zyklisch per Cron ab, erhalte ich folgende Meldungen im Log, wenn das Panel aus ist:
javascript.0 2023-04-19 19:49:50.002 warn at processTimers (node:internal/timers:502:7) javascript.0 2023-04-19 19:49:50.002 warn at listOnTimeout (node:internal/timers:559:17) javascript.0 2023-04-19 19:49:50.002 warn at Timeout._onTimeout (/opt/iobroker/node_modules/iobroker.javascript/node_modules/node-schedule/lib/Invocation.js:228:7) javascript.0 2023-04-19 19:49:50.002 warn at /opt/iobroker/node_modules/iobroker.javascript/node_modules/node-schedule/lib/Invocation.js:268:28 javascript.0 2023-04-19 19:49:50.002 warn at Job.invoke (/opt/iobroker/node_modules/iobroker.javascript/node_modules/node-schedule/lib/Job.js:171:15) javascript.0 2023-04-19 19:49:50.002 warn at Job.job (/opt/iobroker/node_modules/iobroker.javascript/lib/sandbox.js:1595:34) javascript.0 2023-04-19 19:49:50.002 warn at Object.<anonymous> (script.js.Visualisierung.Wallpanel-WZ_aufwecken:40:15) javascript.0 2023-04-19 19:49:50.001 warn getState "vis.0.wallpanel-wz.alive" not found (3)Ok, der State ist gelöscht, daher wird auch das vorherige Script nicht reagiert haben.
Die Frage ist nun, gibt es eine Möglichkeit, trotzdem auf den Datenpunkt zu triggern, wenn das Panel aus ist?Eine Notlösung habe ich schon für mich gefunden, die dann meinem ursprünglichen Vorschlag ähnelt:
Ich trägere auf Aktualisieren, und wenn die Aktualisierung für längere Zeit ausbleibt, dann setze ich mir einen anderen State.
Abr ich würde es gerne erstmal auf "normalem" Weg probieren.Meine Notlösung führt zu dem gleichen Problem mit den Log-Einträgen.
-
@hiltex sagte in ioBroker App 2023 [Android & iOS] - jetzt erhältlich:
Eine Frage zu dem alive-State:
Wie kann man am besten darauf triggern?
Wenn ich auf „ist wahr“ triggere, dann wird der Trigger aller paar Sekunden ausgelöst.
Und andersherum: wie kann ich darauf triggern, dass er nicht wahr ist?Ich stehe gerade auf dem Schlauch
@foxriver76 sagte in ioBroker App 2023 [Android & iOS] - jetzt erhältlich:
@hiltex klingt nach aktualisiert vs geändert im Trigger. Du benötigst geändert.
Ich habe gerade nochmal ein bisschen herumprobiert. Kann sein, dass ich zuerst den Trigger auf aktualisieren gestellt habe und das der Grund war. Es ist jedoch nach wie vor so, dass man nicht auf "nicht wahr" triggern kann.
Ich habe folgendes Blockly dazu gebaut:

Bei alive == true löst das wunderbar aus, aber wenn das Tablet aus geht, dann reagiert das Blockly nicht.
Frage ich das zyklisch per Cron ab, erhalte ich folgende Meldungen im Log, wenn das Panel aus ist:
javascript.0 2023-04-19 19:49:50.002 warn at processTimers (node:internal/timers:502:7) javascript.0 2023-04-19 19:49:50.002 warn at listOnTimeout (node:internal/timers:559:17) javascript.0 2023-04-19 19:49:50.002 warn at Timeout._onTimeout (/opt/iobroker/node_modules/iobroker.javascript/node_modules/node-schedule/lib/Invocation.js:228:7) javascript.0 2023-04-19 19:49:50.002 warn at /opt/iobroker/node_modules/iobroker.javascript/node_modules/node-schedule/lib/Invocation.js:268:28 javascript.0 2023-04-19 19:49:50.002 warn at Job.invoke (/opt/iobroker/node_modules/iobroker.javascript/node_modules/node-schedule/lib/Job.js:171:15) javascript.0 2023-04-19 19:49:50.002 warn at Job.job (/opt/iobroker/node_modules/iobroker.javascript/lib/sandbox.js:1595:34) javascript.0 2023-04-19 19:49:50.002 warn at Object.<anonymous> (script.js.Visualisierung.Wallpanel-WZ_aufwecken:40:15) javascript.0 2023-04-19 19:49:50.001 warn getState "vis.0.wallpanel-wz.alive" not found (3)Ok, der State ist gelöscht, daher wird auch das vorherige Script nicht reagiert haben.
Die Frage ist nun, gibt es eine Möglichkeit, trotzdem auf den Datenpunkt zu triggern, wenn das Panel aus ist?Eine Notlösung habe ich schon für mich gefunden, die dann meinem ursprünglichen Vorschlag ähnelt:
Ich trägere auf Aktualisieren, und wenn die Aktualisierung für längere Zeit ausbleibt, dann setze ich mir einen anderen State.
Abr ich würde es gerne erstmal auf "normalem" Weg probieren.Meine Notlösung führt zu dem gleichen Problem mit den Log-Einträgen.
-
@foxriver76
Ja rein optisch würde ich behaupten er führt den socket Reconnect aus, die Vis Daten werden aktualisiert und dann gibt noch ein Vis Reload mit der weißen seitePassiert natürlich alles sehr fix.
Nur der Socket reconnect wäre das „Ding“


Btw. Vielen Dank für deine Mühe und Aufwand
@dos1973 Wäre das Ding ja und so funktioniert es bei mir lokal auch

Blöd wenn ich es nicht nachgestellt bekomme - kannst du mal die APK ausprobieren bei Gelegenheit
-
@dos1973 sagte in ioBroker App 2023 [Android & iOS] - jetzt erhältlich:
@hiltex
Rein interessehalber, was hast du damit vor?Die Idee dahinter ist, dass grundsätzlich Mitteilungen über Geschehnisse, auf die ich reagieren muss, auf dem Panel angezeigt werden sollen. Wenn das Panel aber aus ist, dann möchte ich einen Teil der Mitteilungen gerne aufs Handy haben. Ich versuche jedoch, möglichst wenige Benachrichtigungen aufs Handy zu bekommen, daher der Versuch zu ermitteln, ob das Panel läuft oder nicht.
-
@dos1973 Wäre das Ding ja und so funktioniert es bei mir lokal auch

Blöd wenn ich es nicht nachgestellt bekomme - kannst du mal die APK ausprobieren bei Gelegenheit
Nein, habe leider ein Ipad…
Aus dem offensichtlichen heraus würde ich sagen der Reload ist überflüssig
und ich habe Zweifel das die Meldung „ Socket Reconnect fehlgeschlagen...“ richtig ist.In der jetzigen Konstellation habe ich allerdings keine Chance zu prüfen ob meine Annahme stimmt.
EDIT:
Ich habe ein Basic Number ins VIS gepackt und da ein Zahl reingeschrieben. Das ipad geht an, der Wert in dem Widget aktualisiert und dann kommt die Meldung reconnect fehlgeschlagen und der Reload startet.Jetzt verstehe ichleider nicht, ob dadurch trotzdem ein socket Fehler bestanden haben kann.
-
Nein, habe leider ein Ipad…
Aus dem offensichtlichen heraus würde ich sagen der Reload ist überflüssig
und ich habe Zweifel das die Meldung „ Socket Reconnect fehlgeschlagen...“ richtig ist.In der jetzigen Konstellation habe ich allerdings keine Chance zu prüfen ob meine Annahme stimmt.
EDIT:
Ich habe ein Basic Number ins VIS gepackt und da ein Zahl reingeschrieben. Das ipad geht an, der Wert in dem Widget aktualisiert und dann kommt die Meldung reconnect fehlgeschlagen und der Reload startet.Jetzt verstehe ichleider nicht, ob dadurch trotzdem ein socket Fehler bestanden haben kann.
-
Nein, habe leider ein Ipad…
Aus dem offensichtlichen heraus würde ich sagen der Reload ist überflüssig
und ich habe Zweifel das die Meldung „ Socket Reconnect fehlgeschlagen...“ richtig ist.In der jetzigen Konstellation habe ich allerdings keine Chance zu prüfen ob meine Annahme stimmt.
EDIT:
Ich habe ein Basic Number ins VIS gepackt und da ein Zahl reingeschrieben. Das ipad geht an, der Wert in dem Widget aktualisiert und dann kommt die Meldung reconnect fehlgeschlagen und der Reload startet.Jetzt verstehe ichleider nicht, ob dadurch trotzdem ein socket Fehler bestanden haben kann.
-
@hiltex sagte in ioBroker App 2023 [Android & iOS] - jetzt erhältlich:
Eine Frage zu dem alive-State:
Wie kann man am besten darauf triggern?
Wenn ich auf „ist wahr“ triggere, dann wird der Trigger aller paar Sekunden ausgelöst.
Und andersherum: wie kann ich darauf triggern, dass er nicht wahr ist?Ich stehe gerade auf dem Schlauch
@foxriver76 sagte in ioBroker App 2023 [Android & iOS] - jetzt erhältlich:
@hiltex klingt nach aktualisiert vs geändert im Trigger. Du benötigst geändert.
Ich habe gerade nochmal ein bisschen herumprobiert. Kann sein, dass ich zuerst den Trigger auf aktualisieren gestellt habe und das der Grund war. Es ist jedoch nach wie vor so, dass man nicht auf "nicht wahr" triggern kann.
Ich habe folgendes Blockly dazu gebaut:

Bei alive == true löst das wunderbar aus, aber wenn das Tablet aus geht, dann reagiert das Blockly nicht.
Frage ich das zyklisch per Cron ab, erhalte ich folgende Meldungen im Log, wenn das Panel aus ist:
javascript.0 2023-04-19 19:49:50.002 warn at processTimers (node:internal/timers:502:7) javascript.0 2023-04-19 19:49:50.002 warn at listOnTimeout (node:internal/timers:559:17) javascript.0 2023-04-19 19:49:50.002 warn at Timeout._onTimeout (/opt/iobroker/node_modules/iobroker.javascript/node_modules/node-schedule/lib/Invocation.js:228:7) javascript.0 2023-04-19 19:49:50.002 warn at /opt/iobroker/node_modules/iobroker.javascript/node_modules/node-schedule/lib/Invocation.js:268:28 javascript.0 2023-04-19 19:49:50.002 warn at Job.invoke (/opt/iobroker/node_modules/iobroker.javascript/node_modules/node-schedule/lib/Job.js:171:15) javascript.0 2023-04-19 19:49:50.002 warn at Job.job (/opt/iobroker/node_modules/iobroker.javascript/lib/sandbox.js:1595:34) javascript.0 2023-04-19 19:49:50.002 warn at Object.<anonymous> (script.js.Visualisierung.Wallpanel-WZ_aufwecken:40:15) javascript.0 2023-04-19 19:49:50.001 warn getState "vis.0.wallpanel-wz.alive" not found (3)Ok, der State ist gelöscht, daher wird auch das vorherige Script nicht reagiert haben.
Die Frage ist nun, gibt es eine Möglichkeit, trotzdem auf den Datenpunkt zu triggern, wenn das Panel aus ist?Eine Notlösung habe ich schon für mich gefunden, die dann meinem ursprünglichen Vorschlag ähnelt:
Ich trägere auf Aktualisieren, und wenn die Aktualisierung für längere Zeit ausbleibt, dann setze ich mir einen anderen State.
Abr ich würde es gerne erstmal auf "normalem" Weg probieren.Meine Notlösung führt zu dem gleichen Problem mit den Log-Einträgen.
@hiltex Also das Tjema "state expires triggern keine changes" wurde mal hier auseinandergenommen
https://github.com/ioBroker/ioBroker.javascript/issues/609#issuecomment-1068835749 ... wie man den quality change korrekt abbildet mit blockly ist die interessante frage
-
@dos1973 thanks ich lade mal die version aus der apk nach testflight, allerdings läuft es auf meinem ipad air mit gleichem iPadOS mit einfachem socket reconnect. (App 1.0.15)
Ok, Testflight 1.0.16(2) habe ich installiert. Ich beobachte…
EDIT:
Ich will ja nicht zu schnell positiv melden, aber es schaut gut aus.
Ipad geht an, wert aktualisiert, Keine Meldung kein Reload.
Ich muss mal beobachten wenn das ipad mal länger als 2 min in standby geht.