NEWS
Test Adapter SmartControl 0.2.x GitHub (ab 18.08.20)
-
Thematik "Homematic-Bewegungsmelder" und Timer habe ich nun hier als Issue angelegt.
https://github.com/Mic-M/ioBroker.smartcontrol/issues/22
Dauert aber aus Zeitgründen noch mehrere Tage, da es "Umbauarbeiten" erfordert, die zeitaufwändig sind.
-
@Mic
@Kueppert
Danke euch beiden
Zwei Geräte, zwei Auslöser und dann zwei Zonen.
Funktioniert.
Wenn man die Logik dahinter mal kapiert hat scheint das ganz gut zu klappen.Jetzt habe ich das nächste Ereignis:
DECT Thermostat soll bei Fenster offen auf den Wert 1 gesetzt werden und wenn geschlossen auf den Wert 0
-- außer wenn der Datenpunkt "Summer active" auf true steht ---Gerät angelegt - ein =1 aus=0
zusätzliche Bedingung angelegt - Datenpunkt Summer active - true
Auslöser angelegt - Datenpunkt Fenster offen - trueZonen - Auslöser ???
Hier sollte jetzt doch nach meinem Verständnis der Auslöser Fenster und die zusätzliche Bedingung eingetragen werden. Die Bedingung erscheint aber nicht in der Auswahl.
Alternativ könnte auch die Bedingung im Auslöser angelegt werden, aber hier ist es nur möglich bei zeitgesteuerten Auslösern zusätzliche Bedingungen auszuwählen. -
@Chaot sagte in Test Adapter SmartControl 0.2.x GitHub (ab 18.08.20):
Zonen - Auslöser ???
Hier sollte jetzt doch nach meinem Verständnis der Auslöser Fenster und die zusätzliche Bedingung eingetragen werden. Die Bedingung erscheint aber nicht in der Auswahl.
Alternativ könnte auch die Bedingung im Auslöser angelegt werden, aber hier ist es nur möglich bei zeitgesteuerten Auslösern zusätzliche Bedingungen auszuwählen.Danke für deine Tests
Alternativ könnte auch die Bedingung im Auslöser angelegt werden, aber hier ist es nur möglich bei zeitgesteuerten Auslösern zusätzliche Bedingungen auszuwählen.
Verstehe dich gut, das scheint verwirrend, dass nur "Zeitabhängige Auslöser" zusätzliche Bedingungen erlauben.
Grund hierfür: Es ist eben ein zeitabhängiger Auslöser, und der bietet relativ wenig, halt Cron oder konkrete Zeitangabe. Mit den "Zusatzbedingungen" will ich ermöglichen, dass der User das noch "feiner" limitieren kann. Außerdem um hier ggf. doppelte Zonen ggf. zu vermeiden.Aber letztendlich greift für alle Auslöser hier "4. ZONEN" > "Ausführung", also was dort eingestellt ist, wird dann auch wirklich und letztendlich geschaltet. Für die zeitabhängigen Auslöser wird da halt schon vorher ausgefiltert.
In deinem Beispiel zB
-
@Mic Ah, da ist das versteckt.
Das habe ich in der Anleitung dann anders gelesen.
Da sollte man vielleicht schreiben das sich unter "Ausführen" weitere Bedingungen einstellen lassen.Nicht böse sein, aber ich werde in den nächsten Tagen versuchen mehrere meiner Scripts über den Adapter zu steuern. Dabei werde ich bewusst die Anleitungen nur überfliegen um zu sehen ob sich das Ding auch weitgehend intuitiv bedienen lässt. Erst wenn ich da auf die Nase falle gehe ich an die Anleitung. Was ich dann dort nicht finde oder verstehe werde ich dann hier posten.
Ich denke mal das die einfache Bedienung genauso wesentlich sein dürfte wie die korrekte Funktionsweise.So wie ich das sehe könnte das eine recht gute Alternative zu der furchtbar schlecht übersetzten Blockly Konstruktion sein. Vor JS schrecken dann erst recht sehr viele (gerade neue) Nutzer zurück. Genau dafür dürfte das der perfekte Adapter werden.
-
@Chaot
Danke, jedes Feedback hierzu ist willkommen.Da sollte man vielleicht schreiben das sich unter "Ausführen" weitere Bedingungen einstellen lassen.
Wo genau würdest du das erwarten? Im Tab "4. ZONEN" steht bereits:
Bin da für konkrete Verbesserungsvorschläge sehr offen.
-
@Mic Ach, ich war nur auf der ersten Seite mit der Konfiguration.
Hier führst du alles zusammen, in dem du alle "Zonen" definierst (z.B. Badezimmer 1.OG, Kaffeeecke, usw.) und Auslöser und zu schaltende Zielgeräte zuweist, sowie auch weitere Bedingungen zur Ausführung definierst.
Unter "Ausführung" gerade mit dem Uhrsymbol würde ich jetzt so intuitiv nicht suchen.
Eventuell wäre das die Überschrift "Bedingung" oder "Konditionen" treffender.Was ich nicht ganz verstehe:
Ich kann unter "Auslöser" einen Cronjob anlegen.
Später in Zonen kann ich dann nochmal eine Zeitsteuerung eingeben. Macht das wirklich Sinn oder sorgt das eher für Verwirrung weil die User dort versuchen werden Cronjobs einzugeben. -
@Mic ich bekomme ne simple Schaltung nicht zum laufen,
möchte abhängig vom battery level, eine (Sonoff)Steckdosenleiste an/aus schalten
das ganze eigentlich noch mit zusätzlicher Bedingung (habe ich aber erstmal rausgenommen) zur Vereinfachung, aber irgendwie will das nicht greifen, es passiert nichts. sämtliche Varianten mit > / >= / = oder auch < / <= / =Zielgerät
Anderer Auslöser
Zone
-
@Chaot sagte in Test Adapter SmartControl 0.2.x GitHub (ab 18.08.20):
Eventuell wäre das die Überschrift "Bedingung" oder "Konditionen" treffender.
Nehme ich auf.
Was ich nicht ganz verstehe:
Ich kann unter "Auslöser" einen Cronjob anlegen.
Später in Zonen kann ich dann nochmal eine Zeitsteuerung eingeben. Macht das wirklich Sinn oder sorgt das eher für Verwirrung weil die User dort versuchen werden Cronjobs einzugeben.Auslöser sind ja z.B.:
- Wandschalter wird gedrückt
- Bewegungsmelder löst aus
- Fenster wird geöffnet
- oder eben z.B. "Donnerstag um 16:00" tritt ein.
In Zonen dient die Zeitsteuerung dazu, ob tatsächlich geschaltet wird. Das mag bei "Zeitabhängiger Auslöser" überflüssig klingen, aber auch hier, gerade in größeren Konfigurationen, einige Use Cases gerade in Verbindung mit mehreren Zonen. Wenn man das nicht braucht, in den Zonen "Immer" anklicken.
-
@crunchip sagte in Test Adapter SmartControl 0.2.x GitHub (ab 18.08.20):
@Mic ich bekomme ne simple Schaltung nicht zum laufen,
möchte abhängig vom battery level, eine (Sonoff)Steckdosenleiste an/aus schalten
das ganze eigentlich noch mit zusätzlicher Bedingung (habe ich aber erstmal rausgenommen) zur Vereinfachung, aber irgendwie will das nicht greifen, es passiert nichts. sämtliche Varianten mit > / >= / = oder auch < / <= / =Gerade getestet und funktioniert bei mir mit Datenpunkt
smartcontrol.0.Test.brightness.Bathroom_bri
als Auslöser.
Teste bitte auch mal mit diesem Datenpunkt bei dir.
Was gibt denn das hier aus (JavaScript-Adapter)?
/** * Hey crunchip ;) * Gib hier mal den Datenpunkt des Battery-Levels ein: */ const stateBattery = 'xyz'; const battStateVal = getState(stateBattery).val; log(`[${stateBattery}] : Variablen-Typ: ${typeof battStateVal}, Wert: '${battStateVal}'`);
-
@Mic sagte in Test Adapter SmartControl 0.2.x GitHub (ab 18.08.20):
Was gibt denn das hier aus
javascript.0 (1053) script.js.test-smartcontrol: [iogo.0.Mario.battery.level] : Variablen-Typ: number, Wert: '29'
@Mic sagte in Test Adapter SmartControl 0.2.x GitHub (ab 18.08.20):
Teste bitte auch mal mit diesem Datenpunkt bei dir.
hab ich jetzt so eingetragen, Steckdose geht aber nicht an
-
@crunchip sagte in Test Adapter SmartControl 0.2.x GitHub (ab 18.08.20):
[iogo.0.Mario.battery.level] : Variablen-Typ: number, Wert: '29'
Genau so sollte es sein
Hast du mal folgendes getestet?
@Mic sagte in Test Adapter SmartControl 0.2.x GitHub (ab 18.08.20):
Gerade getestet und funktioniert bei mir mit Datenpunkt smartcontrol.0.Test.brightness.Bathroom_bri als Auslöser.
Teste bitte auch mal mit diesem Datenpunkt bei dir. -
@crunchip sagte in Test Adapter SmartControl 0.2.x GitHub (ab 18.08.20):
hab ich jetzt so eingetragen, Steckdose geht aber nicht an
Hast du denn den Datenpunkt auch geändert?
-
@Mic ja
-
Also in den Objekten den Datenpunkt geändert, und es hat nicht ausgelöst?
-
@Mic upps, das Stand noch auf null, hab nun 50 eingetragen, Steckdose ist an
-
ok, das heißt es geht also prinzipiell, nur nicht mit deinem Batteriedatenpunkt.
Hat sich denn dieser geändert? Denn nur dann wird ausgelöst. -
@Mic ja der ändert sich, zwar nicht jedes einzelne Prozent, aber das spielt ja keine Rolle, wird vom iogo Adapter/App gesteuert/übertragen.
Ich teste ja schon ne Ewigkeit, da wurde der DP schon etliche male aktualisierthab battery level Wert 36 im controller hinterlegt zum ausschalten, schaltet einfach nicht mit diesem DP, warum auch immer??
{ "type": "state", "common": { "name": "battery level", "desc": "battery level of device Mario", "type": "number", "role": "value.battery", "min": 0, "max": 100, "unit": "%", "read": true, "write": false },
Edit: @nis hab folgendes Problem, möchte den DP , zum schalten verwenden, kann ich aber leider nicht, da hier "ack:false"
kannst du das was machen? -
@crunchip
Da steht "Bestätigt: false", warum ist das so? Adapter-Datenpunkte müssen nämlichack:true
sein. -
@Mic das kommt so vom Adapter,
aber dann haben wir ja den "Fehler" -
@crunchip sagte in Test Adapter SmartControl 0.2.x GitHub (ab 18.08.20):
aber dann haben wir ja den "Fehler"
Warum bestätigt der Adapter nicht mit true?
Aus https://github.com/ioBroker/ioBroker.docs/blob/master/docs/en/dev/adapterdev.md
"Status" has "ack" flag as true and indicate that it is from device or service. E.g. if the weather adapter got new weather forecast, it will be published with ack=true or if homematic thermometer measures new temperature, it will be published with ack=true too. Even if the user physically will switch the light on, the new state will be published with ack=true.
Fehler des iogo-Adapters? Dann bitte dort ein Github-Issue aufmachen.