airStudio 10: MagicLight Unterstützung und mehr

[Blackbird]

@Blackbird

Frage: Was sind das für Klienten, die da adressiert werden? Handys? Wenn ja ist das vielleicht so, dass diese um Strom zu sparen, das WLAN in eine Art Sleepmodus fahren und somit nicht erreichbar sind. Ich habe das Verhalten oft bei Android-Geräten gesehen, die plötzlich in meiner Fritze zwar im Netzwerk als Aktiv mit dem grünen Punkt zu sehen waren, aber die Weltkugel war aus. Das selbe Verhalten zeigt sich bei meinem testweise einbezogenen Samsung TV. Der ist lange im Standby, erscheint aber als aktiv in den Markern. Schalte ich diesen wieder ein, dauert es bis zu 5 Minuten, bis er übers WLAN wieder erkannt wird. Alle meine PCs, die ich zum testen mal eingebunden habe (6 St.) wurden einwandfrei erkannt, wenn sie aus dem S3 aufgewacht waren.

Wenn es Handys sind, kannst Du ja alle neben dich legen und aktiv halten. Wenn dann der Ping bei allen funktioniert, dann hast Du die Bestätigung, dass sie Strom sparen, wenn sie den Bildschirm ausgeschaltet haben.

Dann ist es ja auch so, dass er ja viermal hintereinander läuft. Ich denke die Szene läuft zum nächsten Schritt, wenn der vorherige Klient geantwortet hat, oder nach der vierten Wiederholung als erledigt betrachtet wird. Wenn Du jetzt zu schnell hintereinander die vier Aktoren ansprichst, glaube ich, dass der LM das gar nicht verarbeiten kann...

Gruß Uwe

Vielen Dank, dass Ihr versucht mir zu helfen!
Dafür habe ich ja das Video gemacht, dass man sieht, was da passiert.
Es sind Handys, ja. Aber man sieht, dass die im Skript alle 3 korrekt antworten weil erreichbar. Das Skript hab ich mir gebaut und Tage und Wochenlang laufen lasssen um eben zu sehen, ob eines unserer aktuellen Handys in einen Deepsleep geht. Tun sie nicht.
Gleiches gilt fürs Log. Auch das Toggeln der Marker wird nicht korrekt gelogt, es geht nicht nur um die Pings.
Wie in einem vorherigen Beitrag schon mal geschildert, kann ich auch einen Trust-Aktor schalten. Das wird dann im Interface grün quittiert und weiter passiert nichts. Nach Übertragen der Konfig taucht das Zeug dann in den Logs auf und der Aktor wird auch erst dann geschaltet.
Genauso, wie bei mir bei FW-Updates 9.9.5.4<>10 am Ende immer ein Aktor geschaltet wird, nicht jedoch beim Neustart per Stecker ziehen oder so. Ursache unbekannt. jbMedia hat die Konfig.>> AM lmAir/FW kann es nicht liegen. Ich hab nochmal ein Video gechickt, in dem zu sehen ist, dass es eindeutig mit dem FW-Update zusammen hängt. Keine Reaktion mehr seitdem.

[holzfred]

Hallo,

das hört sich für mich aber langsam nach einem Problem in der WLAN Verbindung des LM an. Aber das nehme ich an, hast Du bereits versucht. Ich muss aber auch gestehen, dass ich meine, dass die Sendeleistung des LM seit der letzten Betas abgenommen hat. Ich habe drei Rolladen, die per ITL-500 gesteuert werden. Jeder ITL hat einmal eine eigene Adresse zur Einzelsteuerung und eine für alle gleiche Adresse zur Gesamtsteuerung. Seit den letzten Betas kommt es immer wieder mal vor, dass ein Rolladen beim senden der Gemeinschaftsadresse nicht reagiert. Mal ist es der in der Küche, der stehen bleibt, mal einer der beiden im Wohnzimmer...

In meinem Bad das gleiche Problem. Die Deckenleuchte hat zwei Adressen. Eine zum Schalten mit dem Sender direkt und eine für den LM. Der Taster ist zusätzlich im LM zum Schalten des Markers hinterlegt. In letzter Zeit kommt es vor, dass die Lampe schaltet, aber der LM den Empfang des Tasters zwar mit rot quittiert, aber der Marker nicht gesetzt wird...

Seltsam.

[jbmedia]

Ich dachte pings werden nicht geloggt?

Genau so ist es! Auch die LED wird dabei nicht eingeschaltet. Damit soll vermieden werden, dass der Log aus Tausenden von Pings besteht und die LED am Light-Manager ständig blinkt.

Aktiviert wird dies über die Option "LED nicht aktivieren". Diese wird automatisch gesetzt, wenn einer Szene ein Ping hinzugefügt wird und sorgt auch dafür, dass nicht geloggt wird. Man kan die Option abschalten (Kontextmenü Szene).

[jbmedia]

Aber man sieht, dass die im Skript alle 3 korrekt antworten weil erreichbar.

Die Sache ist nicht so ganz trivial, wie es auf den ersten Blick scheint. Vor allem können wir die Konfiguration nicht einsehen, daher ist eine Analyse kaum möglich. Die erste Vermutung wäre folgende: Das Handy war bei Eingabe der IP-Adresse in airStudio nicht aufgeweckt und hat daher auf die MAC-Abfage nicht geantwortet. Daher geht airStudio davon aus, dass das Zielgerät in einem anderen Subnetz liegt und nimmt die MAC des Routers. Also sollte zunächst die hinterlegte MAC geprüft werden.

Ich hab nochmal ein Video gechickt, in dem zu sehen ist, dass es eindeutig mit dem FW-Update zusammen hängt. Keine Reaktion mehr seitdem.

Bekanntlich haben wir dieselbe Konfiguration mit diversen airStudio und Firmware Versionen übertragen, ohne dass irgendein Signal gesendet worden wäre. Ein entsprechendes Video wurde ebenfalls erstellt. Welche Reaktion wird noch erwartet?

[Simon]

Thema Ping / WoL und Smartphones sind ein eigenes Thema

Ich habe, seit dem ich Imperihome eingebunden habe, generell Probleme (zwar gelöst) auf allen devices seit her, dass die Kamera bei Bewegung das Device aufweckt und das Display anmacht.
Hört sich simpel an ist aber u.U. mit massiven Mehraufwand und anderen Apps nur möglich (Motion detector, Tasker etc.pp.), wenn das Device keinen eigenen Näherungssensor hat wie es das früher mal gab.
Bei manchen benötigt es aber einen wakelock oder einen wlan fix, damit das device danach ordentlich sich mit dem Netz wiederverbindet bzw. überhaupt mal wieder aus dem Dornröschenschlaf erwacht.

Heisst, offenbar ist das, was bei einem ethernet LAN pc standardisiert ist, nicht gang und gebe bei Android telefonen z.B. Fast jedes Tablet / Smartphone agiert hier offenbar vollkommen unterschiedlich - ist zumindest bei mir der Fall. Ping / WoL an standardiserten LAN-Netzen ist ohne Problem möglich....bei Android WLAN ist immer irgendwas.....

Möglicherweise ist das hier ähnlich. Die Grundfunktion kann JBMedia zur Verfügung stellen, das Problem dahinter muss man am Client dann selber lösen.

Generell würde ich in der szene eh nach jedem Befehl ne Pause setzen von 1s oder so...

[jbmedia]

Die Grundfunktion kann JBMedia zur Verfügung stellen, das Problem dahinter muss man am Client dann selber lösen.

In der Tag, bei mobilen Devices ist das Verhalten sehr komplex. So werden z.B. im Standby Pings deutlich länger beantwortet als Arp-Requests (zur MAC-Adressauflösung). Diese werden u.U. überhaupt nur dann beantwortet, wenn das Display eingeschaltet ist.

Nach allen bisherigen Tests funktioniert die Ping Funktion einwandfrei. Um trotzdem zusätzliche Transparenz zu schaffen, haben wir in der Beta-u, welche nun online ist, folgende Änderungen eingeführt:

Bei einem Ping Befehl erscheint im Log-File die ermittelte Pingzeit in Millisekunden, bzw. -1 bei einem Timeout. Logging erfolgt nur bei manuell ausgelöstem Befehl oder wenn die Option "Ohne LED und Logging" deaktiviert ist. Dies empfiehlt sich aber nur für Testzwecke. Bitte beachten: Ein Ping kann im Falle eines Timeouts bis zu 5s dauern. Es ist immer nur ein Ping gleichzeitig aktiv. "Wildes" Rumklicken führte also dazu, dass Ping Abfragen nicht beendet werden.

Außerdem warnt airStudio nun, wenn die MAC nicht ermittelt werden konnte und stattdessen die MAC des Routers verwendet wird (für andere Subnetze).

1.jpg (66.52 KiB) 7595 mal betrachtet

[Blackbird]

Die erste Vermutung wäre folgende: Das Handy war bei Eingabe der IP-Adresse in airStudio nicht aufgeweckt ...
Also sollte zunächst die hinterlegte MAC geprüft werden.

Bekanntlich haben wir dieselbe Konfiguration mit diversen airStudio und Firmware Versionen übertragen, ohne dass irgendein Signal gesendet worden wäre. Ein entsprechendes Video wurde ebenfalls erstellt. Welche Reaktion wird noch erwartet?

Zum Zeitpunkt, als das Video aufgenommen wurde, hab ich ja fleissig getestet, die Handys waren also alle "aufgeweckt.
Die MAC passt natürlich, solche Dinge prüfe ich gewissenhaft, bevor ich eine "geht nicht"-Meldung absetze.
Ausserdem ging es ja nicht nur um das eine Gerät im Video, ich hatte ja geschrieben, dass die Ergebnisse ganz unterschiedlich ausfallen können, obwohl alle 3 per Skript erreichbar sind.
Eben dieses Skript habe ich mir mit Ankündigung der Ping-Funktion angelegt, um zu sehen, ob das
für meine Zwecke überhaupt nutzbar ist. Dabei hat sich gezeigt, dass keines unserer Handys in einen Deppsleep geht.
Alle 3 Android. Je ein Galaxy S10e, ein Galaxy Note9 und irgendein China-Knaller.

Mit dem unbeabsichtigten Schalten eines Aktors nach FW-Update kann ich leben, so oft macht man das ja nicht.
Das Video hatte ich natürlich gesehen. Ich hatte aber auch die Frage beantwortet, dass wir zwar Funkbus-Sender im Haus haben,
diese aber ausschliesslich mit dem lmAir verbunden sind und nichts direkt schalten. Es wurde ja angemerkt, das Theorie und Praxis zwei verschiedene Dinge sind. Daher habe ich nochnmal ein ausführliches Video aufgenommen, in dem eindeutig zu sehen ist, dass das Schalten mit dem Update in Verbindung steht. Für Interessierte... https://youtu.be/UbumcCE1YKU

Die ""10u" ist ein Traum
Die Pings "laufen sauber durch". Danach stattfindende Aktionen wie z.Bsp. das Toggeln von Markern werden wieder gelogt.
Dass das eben nicht nur Pings betraf wurde scheinbar überlesen.
Aktoren nach Pings lassen sich wieder schalten und werden nicht etwa erst nach erneutem Übertragen der Konfig. auf einen Schlag nachträglich ausgeführt.
Super, Danke!

[rtwl]

@blackbird
du gehörst sicher zu den erfahrensten user hier im forum, und nehme an du hast es sicher kontrolliert, aber könnte es sein, dass dieser Aktor einer Temperatur oder Zeit Szene zugeordnet ist, welche eben ausgelöst wird nach einer Übertragung?

[Blackbird]

@blackbird
du gehörst sicher zu den erfahrensten user hier im forum, und nehme an du hast es sicher kontrolliert, aber könnte es sein, dass dieser Aktor einer Temperatur oder Zeit Szene zugeordnet ist, welche eben ausgelöst wird nach einer Übertragung?

Nee, das hatten wir kontrolliert.
jbMedia hat ja meine Konfig und mir ein Video geschickt, dort wurde nichts gesendet.
Das ist ja das Komische, ich glaube das ja. Und dennoch passiert es bei mir in der Realität.
Deshalb hatte ich ja nochmal die Aufnahme gemacht.
Ich hatte das x-mal durchgeführt und bei JEDEM FW-Update-Vorgang ist das geschehen, so wie im Video gezeigt.
Ich habe nur 2 Temperatur-gesteuerte Szenen, in denen wird nur ein Marker ein und aus geschaltet.
Wie gesagt, damit kann ich ja leben. Der Rest funktioniert mit der "u" jetzt ja auch zufrieden stellend.
Vielleicht "stirbt" mein Gerät ja auch? Es müsste eines der aller Ersten sein . Wie lange ist das her? Knapp 8-10 Jahre oder so?
Ich vermute eher, dass da software-mässig vielleicht irgendwelche "Reste" aus alten Konfigs/Firmwares die Ursache sein könnten.
Wie genau das bei dieser Anwendung unter der Haube gehandhabt wird weiss ja keiner von uns. Ich hab jedenfalls schon die dollsten Dinger erlebt...

[rtwl]

Ja das dachte ich mir eh, dass du (ihr) das gecheckt habt. Oft denkt man aber immer so kompliziert und vergisst die einfachsten Sachen.

was passiert eigentlich wenn du diesen Aktor mal aus der konfig löscht dann FW update, dann wieder hinzufügen.
startet dann ein anderer, oder ist es eventuell danach behoben?