Wenn dies dein erster Besuch hier ist, lies bitte zuerst die Hilfe - Häufig gestellte Fragen durch. Du musst dich vermutlich registrieren, bevor du Beiträge verfassen kannst. Klicke oben auf 'Registrieren', um den Registrierungsprozess zu starten. Du kannst auch jetzt schon Beiträge lesen. Suche dir einfach das Forum aus, das dich am meisten interessiert.
OK, ich musste bei mir noch composer nachinstallieren mit
Code:
sudo yum install composer
Der Fehler ist jetzt weg, aber an A14 kommt nur eine Meldung "{"ready":true,"connectionId":"TedIEeHyjoECGtb="}" , beschäftige ich mich morgen genauer mit.
Ich danke Dir für die Umstellung und deinen Einsatz.
Könnte man den Inhalt vielleicht direkt in den LBS integrieren?
Ich mag sowas auch nicht, aber leider ist das bei so speziellen Sachen immer so eine Sache. Man nimmt entweder ein fertige Klasse/Bibliothek o.ä. oder man setzt sich hin und programmiert das ganze selber. Je nach Komplexität, Größe der Klasse und verfügbarer Freizeit muss man da halt abwägen. Hier habe ich mich zunächst für das Fertigprodukt entscheiden, da PHP das so out-of-the-box nicht mitbringt. Wenn sich jemand findet, der das ganze in den LBS mit reinbekommt, immer her damit. Einfach den Baustein modifizieren und rüber schicken ;-)
Ich habe auch immer so meine Bedenken bei solchen LBS, aber irgendwann habe ich mich von einem Vanilla EDOMI verabschiedet und akzeptiert, dass es sinnvoll ist für bestimmte Probleme auf fertige Lösungen zu setzen.
Es ist auch etwas mehr als eine Klasse, sonst hätte ich die mit reinkopiert. Bei der Basis-Klasse für die API-Abfrage habe ich das auch so gemacht.
Das Problem ist das "autoload.php" nicht gefunden wird
Du musst die beiden Befehle aus der Hilfe im Terminal ausführen. Sonst wird es leider nicht funktionieren. Der LBS funktioniert jetzt ausschließlich auf Websocketbasis für die Status- und Positionsmeldungen.
Das ist ne externe Klasse,die wiederum wieder andere Abhängigkeiten hat. Diese werden mittels composer nachinstalliert. Ich bin kein Freund von sowas, manchmal geht es aber nicht anders.
Edit: Sollte das für alle Ausgänge gelten? Oder vielleicht nur für den API-Ausgang?
Bei meinen dauerlaufenden EXE-LBS nutze ich nur noch logic_getInputsQueued($id[,$fallback[,$sync]]) und logic_setOutput($id,$ausgang,$value).
Notwendig ist es, meine ich zumindest, nur dort wo sich Ein- oder Ausgänge schnell ändern können...
Das Problem ist das "autoload.php" nicht gefunden wird, wo kommt dies Skript den her? Könnte man den Inhalt vielleicht direkt in den LBS integrieren?
Momentan bekomme ich allerdings noch eine Fehlermeldung in der Zeile 3 (require(dirname(__FILE__) . "/../../../../main/include/php/vendor/autoload.php") weil autoload.php nicht gefunden wird.
Das habe ich nicht dazu geschrieben. Für die Websocket-Verbindung habe ich eine fertige Lösung benutzt. In der Hilfe steht dazu:
Daher wird der LBS von panzaeron wahrscheinlich so direkt erstmal nicht funktionieren. Der JSON-String vom Websocket sieht auch etwas anders aus. Die Übersetzung der verschiedenen Codes (Status, Modus, Aktivität und Fehler) habe ich versucht mit einzubauen. Ich kann aber auch noch Änderungen vornehmen, damit es für panzaeron nicht so aufwändig wird den LBS zu korrigieren. Vielleicht ein Output-Slot für jeden Eventtyp oder so.
Wow, vielen Dank für die Überarbeitung
Für meinen LBS ist es am einfachsten, wenn alle Meldungen direkt an A15 ausgegeben werden. Du kannst auch statt logic_setOutput($id,$ausgang,$value) den Befehl logic_setOutputQueued($id,$ausgang,$value) verwenden, dann gehen auch bei einem kurzen hintereinander Ausgeben von Werten, keine Meldungen verloren.
Momentan bekomme ich allerdings noch eine Fehlermeldung in der Zeile 3 (require(dirname(__FILE__) . "/../../../../main/include/php/vendor/autoload.php") weil autoload.php nicht gefunden wird.
ich denke ich habe eine lauffähige Websocket-Version (v0.4) hinbekommen. Der LBS läuft bei mir erst seit zwei Tagen. Kann also noch nicht viel über das Verhalten im Fall eines Fehlers beim Automower sagen. Ende des Monats wird sich zeigen, ob es wieder zu diesen Zugriffsproblemen bei der API kommt.
Der ganze LBS basiert jetzt auf der Vorlage von gaert "EXEC-Script als Dämon". Das heißt, dass der LBS mit EDOMI per gesetztem Eingang E1 automatisch gestartet wird und dann in einer Endlosschleife mit einem Intervall von 50ms läuft. Das heißt die "Zykluszeit" aus dem alten LBS entfällt.
Der LBS lauscht am WebSocket und reagiert bei eingehenden Nachrichten. Diese werden von der API in drei Typen eingeteilt: "Status-event", "Position-event" und "Settings-event". Die aktuelle Version reagiert auf die beiden ersten Events und aktualisiert die zugehörigen Ausgänge. Der Ausgang API-Output enthält immer den letzten empfangenen Event oder ggf. Fehlermeldungen. Daher wird der LBS von panzaeron wahrscheinlich so direkt erstmal nicht funktionieren. Der JSON-String vom Websocket sieht auch etwas anders aus. Die Übersetzung der verschiedenen Codes (Status, Modus, Aktivität und Fehler) habe ich versucht mit einzubauen. Ich kann aber auch noch Änderungen vornehmen, damit es für panzaeron nicht so aufwändig wird den LBS zu korrigieren. Vielleicht ein Output-Slot für jeden Eventtyp oder so.
Die Fehlerwerte für den LBS muss ich mal noch dokumentieren. Die Idee hinter dem Ausgang (A16) ist, dass man nur bei 0 (= fehlerfrei) nachfolgende Aktionen auslösen würde um keine fehlerhaften Informationen auf der Visu oder im Archiv zu haben.
Die Befehle an den Mäher sind nach wie vor noch nicht implementiert. Hier muss ich noch ran, damit man auch über Edomi entsprechende Befehle senden kann.
Die Ausgänge musste ich leider neu Anordnen, damit es etwas übersichtlicher wird. Die Message vom Websocket enthält auch noch informationen über den nächsten Startzeitpunkt oder das geplante Ende der Mähzeit. Das werde ich auch noch mit ausgeben. Allerdings werden sich dann die Ausgänge nochmal verschieben.
Versteh ich nicht.... Über Websockets kommen die Stati, so ganz ohne Abfragen. Das Senden von Befehlen geht dann über die Rest API. Der geänderte Status kommt wieder über den Websocket. Das machen die homeconnect LBS genau so. Und mehr als 10000 Befehle wird ja wohl keiner im Monat an den Rasenmäher senden. OK, der Initiale Status muss auch darüber abgerufen werden.
Limit exceeded bedeutet Du hast die maximal mögliche Anzahl an Abfragen (pro Monat) überschritten. Im Montat sind es nur 10 000 und bedeutet ein geringeres Intervall als 4-5 Minuten ohne Überschreitung des API-Limits ist nicht möglich. Lösung: Zykluszeit erhöhen oder du legst bei Husqvarna noch weitere Apps an und nutzt z. B. einen API-Key pro Woche.
Wird es hier noch eine andere Lösung geben? Also auch mit V3.2 hab ich nun das Limit erreicht bei Cycletime 60 sek. Ich finde halt wenn man 4-5 min. nehmen muss oder mehrere API Keys ist das ja totaler Quark mit dem LBS.....
Wie ist das bei euch anderen?
Wir verarbeiten personenbezogene Daten über die Nutzer unserer Website mithilfe von Cookies und anderen Technologien, um unsere Dienste bereitzustellen. Weitere Informationen findest Du in unserer Datenschutzerklärung.
Indem Du unten auf "ICH stimme zu" klickst, stimmst Du unserer Datenschutzerklärung und unseren persönlichen Datenverarbeitungs- und Cookie-Praktiken zu, wie darin beschrieben. Du erkennst außerdem an, dass dieses Forum möglicherweise außerhalb Deines Landes gehostet wird und bist damit einverstanden, dass Deine Daten in dem Land, in dem dieses Forum gehostet wird, gesammelt, gespeichert und verarbeitet werden.
weil autoload.php nicht gefunden wird.
Einen Kommentar schreiben: