Vielen Dank, ich teste dann gleich weiter...Die Änderung betraf den "cmd=" Befehl per GET allgemein. Wobei es sich kaum erklären ließe, dass das der Grund für die Fails ist.
Wir haben die Änderung rückgängig gemacht, ein Firmware Update von Server reicht aus.
airStudio 10: MagicLight Unterstützung und mehr
LMAir&2 Extender, 3 X RM3mini, Harmony Elite & 3 X Companion, Deconz Zigbee Gateway, piVCCU, Node-Red (für Anbindung Harmony, Homematic, Broadlink, Dreamscreen, Zigbee), ettliche Aktoren, 8 Alexas, Fritzbox 7590, 7490, 7560, 2 X 4040, 1 X 450 
Kurzer Erfahrungsbericht bezüglich HTTP Request für Marker setzen:jbmedia hat geschrieben: ↑Mi 5. Mai 2021, 10:32
Man kann die Funktion einfach im Browser testen. Dazu http://192.168.1.xxx/control?cmd=typ,smk,0,1 eingeben. Die erste Zahl ist der Marker minus 1 (0-63), die zweite ist ein oder aus. Wir haben dies gerade mehrfach getestet, funktioniert einwandfrei inkl. Logging.
Beim Testen Button im AirStudio kommt: /control?cmd=typ,mka,did,0,acmd,1
jedoch funktioniert diese URL nicht. Auch das Marker Testen ansich funktioniert nicht (mehr?).
Dort wird auch für Ein=1, Aus=2 und Toggle=3 angegeben, was auch falsch ist bzw nicht funktioniert.
korrekt ist das Kommando wie von euch hier vorgeschlagen: /control?cmd=typ,smk,0,1
zu beachten ist, dass "mka" nicht funktioniert, "smk" hingegen schon. Auch das "did" sowie "acmd" darf nicht in die URL, sonst funktionierts auch nicht.
Version 10p - inkl Firmware update (vom Server)
Peter
Funktionierte bei mir anfangs auch nicht, da ich vergessen hatte die Firmware zu aktualisieren. Als ich das nachgeholt hatte, war alles wie es sein soll. Auch ich habe "Autostart" und "Nach Stromausfall" bei einer Szene kombiniert und läuft automatisch weg.
Peter
Skipper hat geschrieben: ↑Di 4. Mai 2021, 22:30Die Thermosensoren sollen abhängig von Temperaturen Marker setzen oder Mails schicken. Das klappt nun auch nicht mehr richtig. Hab versucht das nachzuvollziehen, aber ich komme nicht dahinter. War mit 9.xx auch kein Thema.
Hier hat sich auch nichts verändert. Da jeder Temperatur-Kanal einen Mittelwertfilter besitzt, wodurch Ausreißer gefiltert werden, könnte es im ungünstigen Fall nach einem Neustart vorkommen, dass eine Temperatur-Szene unerwartet einmalig ausgelöst wird. Dies war aber schon immer so und wäre ein äußerst seltener Fall.
Habe nun die Temperatursensoren neu angelernt, das FW Update erneuert und auch die aktuelle 10p an Bord. Leider reagieren die Marker nicht mehr auf Sensoren. Irgendwas ist da jetzt anders !
Ich denke, ich kann ein wenig Licht ins Dunkle bringen, warum Wake-On-Lan nicht bzw. unzuverlässig funktioniert.
Der Vollständigkeit halber, bei mir ist eine 7490 Fritte im Einsatz.
Tatsächlich spielt es kein Rolle, ob die Zielgeräte bei Anlage der WOL-Aktion eingeschaltet sind oder nicht.
Vielmehr ist es die Tatsache, dass dann im Anschluss beim Testen das Gerät erst Sekunden oder Minuten vorher heruntergefahren wurde.
Dann reagieren die Geräte auch noch auf WOL. (Original IP und MAC)
Sind die erstmal ne Weile offline gewesen (ca.30min), dann reagieren die auf keinen WOL Befehl aus airStudio 10 mehr.
Egal auf welchem Wege der Aktor angelegt wurde oder die Aktion ausgelöst wird.
Egal, ob dann 192.168.178.46, 192.168.178.255 oder 255.255.255.255 als IP verwendet wird.
WOL funktioniert nach wie vor (wie schon seit Jahren) per WOL.exe, übers Interface der Fritte als auch über Portweiterleitung von aussen.
Ebenso wachen die Geräte auch über WOL abgesendet von der 9.9.5.4 wieder auf.
Offensichtlich ist das neue "Protokoll" noch nicht einwanfrei "eingebaut/eingestellt" oder
aber für diesen Anwendungszweck nicht besser geeignet als die bisher verwandte Lösung.
Vielleicht trägt diese Beobachtung ja zu Verbesserungen bei...
Der Vollständigkeit halber, bei mir ist eine 7490 Fritte im Einsatz.
Tatsächlich spielt es kein Rolle, ob die Zielgeräte bei Anlage der WOL-Aktion eingeschaltet sind oder nicht.
Vielmehr ist es die Tatsache, dass dann im Anschluss beim Testen das Gerät erst Sekunden oder Minuten vorher heruntergefahren wurde.
Dann reagieren die Geräte auch noch auf WOL. (Original IP und MAC)
Sind die erstmal ne Weile offline gewesen (ca.30min), dann reagieren die auf keinen WOL Befehl aus airStudio 10 mehr.
Egal auf welchem Wege der Aktor angelegt wurde oder die Aktion ausgelöst wird.
Egal, ob dann 192.168.178.46, 192.168.178.255 oder 255.255.255.255 als IP verwendet wird.
WOL funktioniert nach wie vor (wie schon seit Jahren) per WOL.exe, übers Interface der Fritte als auch über Portweiterleitung von aussen.
Ebenso wachen die Geräte auch über WOL abgesendet von der 9.9.5.4 wieder auf.
Offensichtlich ist das neue "Protokoll" noch nicht einwanfrei "eingebaut/eingestellt" oder
aber für diesen Anwendungszweck nicht besser geeignet als die bisher verwandte Lösung.
Vielleicht trägt diese Beobachtung ja zu Verbesserungen bei...
Zuletzt geändert von Blackbird am Do 6. Mai 2021, 09:26, insgesamt 1-mal geändert.
Wie gesagt, der einzige Unterschied ist, dass wol.exe die IP 255.255.255.255 verwendet. Diese kann auch in airStudio hinterlegt werden. Die MAC muss trotzdem stimmen, d.h. diese sollte man zuvor automatisch ermitteln lassen.
Wir wünschen viel Spaß mit den Produkten und einen erfolgreichen Tag! Ihr jbmedia Team 
Sorry, Ihr seid zu schnell, hab eben oben nochmal editiert.
Hi,
witzig... ich habe gerade das Protokoll von heute gezogen und wollte es bearbeiten, denn genau das ist mir auch aufgefallen. Ich habe heute morgen um 6 den Server wecken wollen. Einmal mit einer Szene, in welcher der WOL Aktor angesprochen wird und einmal per Aktor direkt übers WEBIf. Keine Reaktion. Mein Klient, der sich um 5 zur Sicherung auf dem NAS geweckt wurde und um 5:45 wieder in den Standby ging, konnte ich wecken. Das Ganze lief innerhalb des Netzwerks.
Gerade vom Büro aus konnte ich den Klient wieder nicht wecken. Ich habe ihn über FritzApp geweckt, heruntergefahren und 15 Min später konnte ich ihn dann übers WebIF wecken. Seitdem sind 45 min vergangen und das Wecken klappt wieder nicht. Das Protokoll zeigt immer einwandfreie Einträge, die sich nicht unterscheiden.
Ich weiß, dass sich die Fritzbox sehr restriktiv gegen WOL Befehle von außen wehrt. Ich kenne niemanden, der trotz der Erlaubnis in der Fritz, beim Zugriff von außen den Klienten zu wecken, jemals zum Laufen bekommen hat. Selbst wenn ich den Port 9 direkt auf den Klienten leite, klappt das nicht.
Es klappt auch nicht, wenn ich statt meiner DynDNS die direkte IP meines Routers verwende.
Gruß Uwe
witzig... ich habe gerade das Protokoll von heute gezogen und wollte es bearbeiten, denn genau das ist mir auch aufgefallen. Ich habe heute morgen um 6 den Server wecken wollen. Einmal mit einer Szene, in welcher der WOL Aktor angesprochen wird und einmal per Aktor direkt übers WEBIf. Keine Reaktion. Mein Klient, der sich um 5 zur Sicherung auf dem NAS geweckt wurde und um 5:45 wieder in den Standby ging, konnte ich wecken. Das Ganze lief innerhalb des Netzwerks.
Gerade vom Büro aus konnte ich den Klient wieder nicht wecken. Ich habe ihn über FritzApp geweckt, heruntergefahren und 15 Min später konnte ich ihn dann übers WebIF wecken. Seitdem sind 45 min vergangen und das Wecken klappt wieder nicht. Das Protokoll zeigt immer einwandfreie Einträge, die sich nicht unterscheiden.
Ich weiß, dass sich die Fritzbox sehr restriktiv gegen WOL Befehle von außen wehrt. Ich kenne niemanden, der trotz der Erlaubnis in der Fritz, beim Zugriff von außen den Klienten zu wecken, jemals zum Laufen bekommen hat. Selbst wenn ich den Port 9 direkt auf den Klienten leite, klappt das nicht.
Es klappt auch nicht, wenn ich statt meiner DynDNS die direkte IP meines Routers verwende.
Gruß Uwe
LM-Air HW 1.1 und 1.1 Ver. 11
FritzBox 6590 Cable, Unifi Switch 24 PoE, 4 x Unifi AP AC Pro
Philips HUE Bridge - Shellys 2.5 - Intertechno Aktoren
FritzBox 6590 Cable, Unifi Switch 24 PoE, 4 x Unifi AP AC Pro
Philips HUE Bridge - Shellys 2.5 - Intertechno Aktoren
Das ist jetzt ein wenig am Thema vorbei. Aaaaber....holzfred hat geschrieben: ↑Do 6. Mai 2021, 09:48
Ich weiß, dass sich die Fritzbox sehr restriktiv gegen WOL Befehle von außen wehrt. Ich kenne niemanden, der trotz der Erlaubnis in der Fritz, beim Zugriff von außen den Klienten zu wecken, jemals zum Laufen bekommen hat. Selbst wenn ich den Port 9 direkt auf den Klienten leite, klappt das nicht.
Es klappt auch nicht, wenn ich statt meiner DynDNS die direkte IP meines Routers verwende.
WOL von aussen brauchst Du auch nicht.
Richte ein Portforwarding in der Fritte auf das Zielgerät ein und hake an, dass das Gerät bei Zugriff von aussen geweckt werden soll.
Dann http'st Du Deine DynDNS und denport der weitergeleitet werden soll. also... DeineDynDNS:port
Dann macht die Fritte das WOL.
Hey, das könnte auch die Lösung sein, das WOl problem in airStudio zu umgehen....