Test Adapter Worx v0.4.x
-
@worxweis
Finde es jetzt auch nicht passend Worx was von ioBroker in Zusammenhang von Problemen zu erzählen...
Das Worx keine anderen Zugriffe zulässt ist ja bekannt.Ich glaube zwar nicht das Worx sieht das die abfragen vom ioBroker gemacht werden und einen dann Sperren, denke mal das sind einfach zuviele abfragen und deshalb Sperrt Worx.
Problem könnte halt sein wenn Worx die Entwickler anschreibt und den Adapter verbietet. -
@worxweis sagte in Test Adapter Worx v0.4.x:
Habe mich daraufhin an den Support gewandt, da ich ja der Meinung war, das Meistertr, der ja den Adapter geschrieben hat, diesen in Abstimmung mit Worx entwickelt hat.
im ernst.. dass du der Meinung warst.. wie währe es mit NACHFRAGEN bevor man sich aufregt .. bzw eine Welle macht
wenn dein Zugang gesperrt wird und von 100 anderen nicht .. ratemal woran es wohl liegen wird ..
ich würde noch die Merkel und den Papst anschreiben und dein Problem schildern.. die können bestimmt was tun..
du nutzt eine Software die komplett kostenlos ist .. jemand macht sich die Arbeit und schreibt für UNS in seiner FREIZEIT ein Programm mit dem man Informationen bekommt . um diese zu Visualisieren..
na klar da kann man schon mal Meckern.. scheiss iobroker.. aber echt ehh
-
@worxweis sagte in Test Adapter Worx v0.4.x:
Habe mich daraufhin an den Support gewandt, da ich ja der Meinung war, das Meistertr, der ja den Adapter geschrieben hat, diesen in Abstimmung mit Worx entwickelt hat.
Das ist ungefähr so geil wie zur Polizei oder zum Ordnungsamt zu gehen und sich beschweren, das ein bestimmter Blitzer nicht in der Blitzer-App aufgeführt wird ...
Bei aller Liebe .....
-
@worxweis sagte in Test Adapter Worx v0.4.x:
Somit, denke ich, wird sich hier nichts ändern und Worx wird den Zugang von IOBROKER immer wieder sperren.
Du hast aber schon Verstanden das der Support dir gesagt hat das sie keinen Support für Drittanbieter Software leisten?!
Das hat nichts damit zu tun das die API verfügbar ist und auch genutzt werden kann.
Sie sperren nur wenn ein Benutzer zu viel Last verursacht, das ist unabhängig von der Software. Das würde sogar passieren wenn die Offizielle App zu viele Anfragen an den Server stellt. -
Und das https://forum.iobroker.net/post/421753 wurde wohl auch nicht gelesen
-
Dieser Post des Entwicklers sagt genug.... (ist erst 1,5 Monate her)
https://forum.iobroker.net/topic/24231/test-adapter-worx-v0-4-x/38 -
Hallo @skokarl ,@Meistertr
Ich muss nochmals auf das Problem mit dem Online-Status des Mähers im Adapter zurückkommen. Das Wlan hat am Mäher, wenn in der Basis zwei Balken(ca. -60 dBm), sollte also passen. Irgendwo im Garten ist es vermutlich schlechter, mag sein. Jetzt passiert es mir neuerdings regelmässig, dass der Adapter auf mower.online=false geht und dann da bleibt. Und natürlich den Mähstatus nicht mehr aktualisiert. Auch wenn der Mäher brav in der Basis steht. Der Adapter zeigt dann z.B. noch „mowing“. Und zwar genau so lange, bis ich in der Worx-App den Status abrufe.
Ohne dass ich am Wlan fummle, also nur durch ein Polling meinerseits.
Und wenn der Status dann in der App aktualisiert wird, hat sie auch der Adapter.
Ist es jetzt also so, dass sobald der Mäher in ein Wlan-Loch kommt, der Adapter beleidig ist? Aber warum kommt er dann wieder online, wenn ich in der App den Status abrufe, nicht aber sonst? Das verstehe ich nicht.
Wenn ich den Adapter neu starte, aktualisiert es ebenfalls (das ist bekannt, aber auch, dass man sich da wohl ins Abseits schiessen kann, wenn man das zu oft macht).
Was bedeutet denn der Online-Status im Adapter überhaupt, und warum hängt der von der Handy-App ab? -
@womi sagte in Test Adapter Worx v0.4.x:
Der Adapter zeigt dann z.B. noch „mowing“. Und zwar genau so lange, bis ich in der Worx-App den Status abrufe.
Ohne dass ich am Wlan fummle, also nur durch ein Polling meinerseits.Das ist der Ablauf:
- App an MQTT Server: Schick Status!
- MQTT Server an Mäher: Schick Status!
- Mäher schickt Status an MQTT Server
- MQTT Server schickt den Status an alle Subscriber weiter, also nicht nur an die App, sondern auch an den Adapter (und evtl andere Subscriber)
@Meistertr : Mir ist völlig unklar, worauf sich die Online Aussage bezieht. Auf ioBroker, also das heimische Netz? Auf den Wetter-Webserver? Auf den MQTT-Server? Auf den Mäher? Was testet denn der Adapter hier ab?
-
In welchen Abständen fragt der MQTT Server die Daten ab? Das wäre wahrscheinlich des Rätsels Lösung hier.
-
@haselchen sagte in Test Adapter Worx v0.4.x:
In welchen Abständen fragt der MQTT Server die Daten ab?
In diesem gesamten Szenario ist der Mäher der Publisher von Informationen. Der Adapter, die App o.ä. sind die Subscriber der Informationen. Der MQTT Server ist der Makler (Broker) in der Mitte. Im Normalfall schickt der Mäher seinen Status an den MQTT Server. Dieser schickt den Status an alle Subscriber weiter. Wann und wie oft der MQTT Server Informationen vom Mäher bekommt, entscheidet allein der Mäher, niemand sonst.
In der iobroker Logdatei kannst Du im Debug Modus sehen, dass der Mäher alle 10 Minuten was schickt sowie dann, wenn eine wichtige Statusänderung erfolgt. Welche Statusänderungen wichtig sind, entscheidet dabei der Mäher selbst.
Der MQTT Server fordert im Normalfall keine Informationen vom Mäher an, außer wenn er einen Poll-Auftrag von einem Subscriber erhält. Nach meinem Verständnis gibt der Adapter lediglich bei seinem Start einen Poll-Auftrag ab, dann nicht mehr. (Die Zusage mit Polls sparsam unzugehen, war übrigens eine wichtige Bedingung, die Positec gestellt hatte, um den Adapter-Einsatz zu tolerieren,)
Hier gibt's übrigens eine kleine Bettlektüre zum Thema MQTT.
-
Stimmt dann noch der Ablauf den du eben geschrieben hast?
MQTT Server an Mäher = Schick Status
Darunter habe ich was anderes verstanden als das was du jetzt geschrieben hast.
-
@hsteinme
Das klingt alles sehr logisch.
Wenn sich jetzt also der MQTT-Server, die App und der Adapter ruhig verhält, und der Mäher alleinig entscheidet, wann er sich meldet: Was könnte ihn ab und zu dazu bewegen, sich zu entscheiden, sich eben nicht mehr zu melden? Bis er gefragt wird.
Ich nehme an, wenn ich im Adapter irgendwelche Parameter ändere, die den Mäher betreffen, würden die via MQTT-Server an den Mäher weitergereicht. Und dann käme sicherlich auch der Status zurück.
Kann ich vielleicht auf diese Weise eine Art Minimal-Polling (bei Offline) triggern?
Im Moment lasse ich den Adapter lediglich Start- und ggf. schon vor Regen Stoppbefehle senden, mehr nicht.Bedeutet das nebenbei bemerkt dann auch, dass z.B. ein eingestelltes Zeitprogramm ebenfalls im Mäher "wohnt"? Der Mäher ist also, einmal eingestellt, weitestgehend autark?
-
@haselchen sagte in Test Adapter Worx v0.4.x:
MQTT Server an Mäher = Schick Status
Darunter habe ich was anderes verstanden als das was du jetzt geschrieben hast.Wie soll ich mir dazu eine Meinung bilden, solange Du für Dich behältst, wie Dein anderes Verständnis aussieht`?
-
@womi sagte in Test Adapter Worx v0.4.x:
Was könnte ihn ab und zu dazu bewegen, sich zu entscheiden, sich eben nicht mehr zu melden?
Woher weißt Du, wo die Ursache des Problems ist?
- Kann der Mäher keine Information schicken?
- Kann der MQTT Server keine Information empfangen?
- Kann der MQTT Server keine Information weitergeben?
- Kann der Adapter keine Information empfangen?
- Kann der Adapter die Information nicht in den Datenpunkten abstellen?
Meine Empfehlung:
- Stelle die Adapter-Instanz auf den Log-Level Debug ein.
- Falls noch nicht bekannt, schaue Dir an, wie Du die Logdatei eines Mähers auslesen kannst.
- Im Problemfall studiere die Logdateien des Adapters und des Mähers und prüfe, ob dort etwas Auffälliges zu sehen ist, was als Hinweis auf die Problemursache verstanden werden kann.
@womi sagte in Test Adapter Worx v0.4.x:
Ich nehme an, wenn ich im Adapter irgendwelche Parameter ändere, die den Mäher betreffen, würden die via MQTT-Server an den Mäher weitergereicht. Und dann käme sicherlich auch der Status zurück.
Teste es.
@womi sagte in Test Adapter Worx v0.4.x:
Kann ich vielleicht auf diese Weise eine Art Minimal-Polling (bei Offline) triggern?
Und wenn Du es damit übertreibst, wird Dein Account halt für eine Zeit gesperrt werden. Und wenn sehr viele es damit übertreiben, wird halt @Meistertr ein Schreiben von der Positec'schen Rechtsabteilung bekommen.
@womi sagte in Test Adapter Worx v0.4.x:
Bedeutet das nebenbei bemerkt dann auch, dass z.B. ein eingestelltes Zeitprogramm ebenfalls im Mäher "wohnt"?
Stell über App oder Adapter den Zeitplan ein, schalte WLAN aus und schau Dir an, wie der Mäher seine Mähdienste gemäß Zeitplan ausführt.
-
Hatte ich oben schon beschrieben. Ich behalte selten was für mich
- schreibst du das: MQTT Server an Mäher = Schick Status
- schreibst du das: Der MQTT Server ist der Makler (Broker) in der Mitte. Im Normalfall schickt der Mäher seinen Status an den MQTT Server. Dieser schickt den Status an alle Subscriber weiter. Wann und wie oft der MQTT Server Informationen vom Mäher bekommt, entscheidet allein der Mäher, niemand sonst
Nicht zu lange aus dem WLAN lassen, nach 3 Tagen ohne Einwahl ins heimische Netzwerk + bei eingestellter Diebstahlsperre in der App wird der Mäher gesperrt.
Du kannst per USB Stick ein Log auslesen, in dem alle Infos stehen.
Mähzeiten + Zeiten für den Kantenschnitt. -
@haselchen sagte in Test Adapter Worx v0.4.x:
schreibst du das: MQTT Server an Mäher = Schick Status
schreibst du das: Der MQTT Server ist der Makler (Broker) in der Mitte. Im Normalfall schickt der Mäher seinen Status an den MQTT Server. Dieser schickt den Status an alle Subscriber weiter. Wann und wie oft der MQTT Server Informationen vom Mäher bekommt, entscheidet allein der Mäher, niemand sonst- beschreibt den Nicht-Normalfall, wenn durch die Anwahl der App der Adapter Informationen erhält.
- beschreibt den Normalfall, nämlich die Kommunikation Mäher - MQTT Server - Adapter (ohne dass jemand anderes, z.B. die App dazwischen funkt.
-
Wie wäre die Live-Aktualisierung , wenn ich ein 2.Handy benutze , dass nur im WLAN ist und die App geöffnet lasse (sagen wir permanent)?
-
@haselchen sagte in Test Adapter Worx v0.4.x:
Wie wäre die Live-Aktualisierung , wenn ich ein 2.Handy benutze , dass nur im WLAN ist und die App geöffnet lasse (sagen wir permanent)?
Ich habe oben den Ablauf nach einem Poll durch die App beschrieben. Ein Poll wird beim Starten der App durchgeführt oder durch einen Benutzer-Eingriff. Wenn ein Handy "nur einfach so rumliegt" führt, die App keinen Poll durch. Die Aktualisierung würde also immer nur vom Mäher aus erfolgen, nicht von der App aus.
-
@arteck sagte in Test Adapter Worx v0.4.x:
ich mach es so
müsst ihr aber einen Datenpunkt anlegen über den getriggert wird.
let worx = 'worx.0.id_des_mover'; let laufzeit = 60; let plusMinuten = 1; on({id: worx + '.mower.state', change: "ne"}, function (obj) { let stat = getState(worx + '.mower.state').val; if (!stat) { worxLos(new Date(), '00:00', 0); // wenn fertig dann wird wieder alles gelöscht } }); on({id: '0_userdata.0.draussen.worxKantenschnitt', change: "any"}, function (obj) { if (getState('0_userdata.0.draussen.worxKantenschnitt').val) { if (!getState(worx + '.mower.state').val) { // robi muss in der garage sein let jetzt = new Date(); jetzt.setMinutes(jetzt.getMinutes() + plusMinuten ); let los = new Date(jetzt); let startUm ; if (los.getMinutes() < 10) { startUm = los.getHours() + ':0' + los.getMinutes(); } else { startUm = los.getHours() + ':' + los.getMinutes(); } worxLos(los, startUm, laufzeit); } } }); function worxLos(zeitstempel, startUm, laufzeit) { switch (zeitstempel.getDay()) { case 0: setState(worx + '.calendar.sunday.startTime', startUm); setTimeout(function () { setState(worx + '.calendar.sunday.workTime', laufzeit); }, 1000 * 5); // warte 5 sekunden break; case 1: setState(worx + '.calendar.monday.startTime', startUm); setTimeout(function () { setState(worx + '.calendar.monday.workTime', laufzeit); }, 1000 * 5); // warte 5 sekunden break; case 2: setState(worx + '.calendar.tuesday.startTime', startUm); setTimeout(function () { setState(worx + '.calendar.tuesday.workTime', laufzeit); }, 1000 * 5); // warte 5 sekunden break; case 3: setState(worx + '.calendar.wednesday.startTime', startUm); setTimeout(function () { setState(worx + '.calendar.wednesday.workTime', laufzeit); }, 1000 * 5); // warte 5 sekunden break; case 4: setState(worx + '.calendar.thursday.startTime', startUm); setTimeout(function () { setState(worx + '.calendar.thursday.workTime', laufzeit); }, 1000 * 5); // warte 5 sekunden break; case 5: setState(worx + '.calendar.friday.startTime', startUm); setTimeout(function () { setState(worx + '.calendar.friday.workTime', laufzeit); }, 1000 * 5); // warte 5 sekunden break; case 6: setState(worx + '.calendar.saturday.startTime', startUm); setTimeout(function () { setState(worx + '.calendar.saturday.workTime', laufzeit); }, 1000 * 5); // warte 5 sekunden } }Wie würde das in Blockly aussehen?
- „startTime“ auf z.B. 10:00 setzen
- 5 Sekunden Pause
- „workTime“ auf 10 setzen
Was ist mit „borderCut“? Muss das nicht auch noch auf true gesetzt werden? Finde ich in dem Skript nicht.
-
@Sandmanyz der borderCut steht bei mir immer auf true..deshalb setzte ich den nicht im script..mit blockly..kein plan..
würde aber sagen so wie du es beschreibst ja
