Test Adapter shuttercontrol v2.0.x
-
@foxro sagte in Test Adapter shuttercontrol v1.2.x:
Sorry, aber mir fällt es schwer, dir an dieser Stelle noch viel weiter helfen zu können.
Hallo
Hab gleich Antwort von @foxriver76 erhalten.
CCU meldet den Wert so und glaube der DP Working wird auf true gesetzt so lange er fährt. Ich denke über den Working Dp sollte man sagen können, dass es gerade ne aktive Fahrt ist und kein endzustand. Ich denke der Hauptgrund dass gesendet wird von CCU ist auch dieser dp aber der Rollo ist halt schon losgefahren und daher so ein krummer Wert
Eventuell kann @simatec dies als Kontrolle in den Adapter einbauen.
Sind ja sicher einige mit Homematic Komponenten.Bei den Extra-Einstellungen bin ich schon auf 120. Das half auch nicht.
-
@negalein said in Test Adapter shuttercontrol v1.2.x:
Eventuell kann @simatec dies als Kontrolle in den Adapter einbauen.
Sind ja sicher einige mit Homematic Komponenten.Möchte hier keinen Streit vom Zaun brechen - ist eher ein wenig "Religion", muss aber anfügen, so wie ich das iOBroker Konzept bis jetzt verstehe, und wie andere Adapter ihre Endgeräte Spezifika in iOBroker integrieren, dann müsste dies der HM Adapter übernehmen und nicht jeder Adapter, welcher möglicherweise HM Geräte steuert.
Da hält sich zb. der KNX Adapter penibel daran, keine KNX spezifischen Verhaltensweisen in iOBroker rein zu bringen.
Aus meiner Sicht müsste also der HM Adapter dafür sorgen, dass es auf dem Positions DP kein Update gibt, solange der Working DP true ist. Denn wie @foxriver76 selbst schreibt, sind die Werte am Positions DP während dem Fahren ungültig. Ich meinte hier schon Logs gesehen zu haben, wo es während dem Fahren fortlaufend zu Updates kam.Wie geschrieben, die Extra-Einstellung wird an dieser Stelle ausgehebelt, da der DP für die Höhe von Shuttercontrol sogenannt "abonniert" wird und deshalb Änderungen da drauf direkt und ohne Delay in die Logik mit einbezogen werden. Wenn man diese Änderungen durch die Extra-Settings ganz ausblenden würde, dann wäre Shuttercontrol auf dem DP während dieser Extra-Einstellungen Zeit bei jeder Fahrt komplett blind und würde da nichts mit bekommen, egal was passiert. Dh. die Extra-Einstellungen würden wohl plötzlich zu einem kritischen "Fine-Tune" Element. Gute Ideen wären also gefragt, wenn der HM Adapter dies nicht übernimmt
Projektleiter von Shuttercontrol ist und bleibt @simatec und deshalb überlasse ich es ihm, ob und wie er zu diesem Verhalten eine Lösung anbieten will.
-
@foxro sagte in Test Adapter shuttercontrol v1.2.x:
muss aber anfügen, so wie ich das iOBroker Konzept bis jetzt verstehe, und wie andere Adapter ihre Endgeräte Spezifika in iOBroker integrieren, dann müsste dies der HM Adapter übernehmen und nicht jeder Adapter, welcher möglicherweise HM Geräte steuert.
Aus meiner Sicht müsste also der HM Adapter dafür sorgen, dass es auf dem Positions DP kein Update gibt, solange der Working DP true ist.
Da bin ich voll deiner Meinung.
Wenn es beim KNX-Adapter geht, kann es @foxriver76 vielleicht doch im HM-Adapter irgendwie bewerkstelligen.
Es betrifft bestimmt noch andere Adapter oder in Zukunft welche, die mit dem Problem zu kämpfen haben.Ich bin kein Entwickler, kenne mich also 0 aus ob das möglich ist.
Muss oder kann nur @foxriver76 entscheiden. -
Hallo zusammen,
aktuell habe ich meine Rollo-Steuerung per Blockly realisiert und wollte mir jetzt mal diesen Adaopter anschauen.
Bevor ich anfange zu testen, habe ich direkt mal eine Frage:
Kann man Fenstersensoren integrieren, damit die ROllos nur auf z.B. 25% fahren, wenn ein Fenster gekippt ist?
-
@kuddel
ja, ist möglich! -
@kuddel die frage ist eher umgekehrt, können deine rollos alles das, was shuttercontrol kann!
-
@da_woody
Welches Rollo kann das denn?
Grinsduckundwech -
nochmal eine Frage zu den Shuttercontrol States:
soll es denn eigentlich so sein, dass jedes manuelle Hochfahren auf das Level 100%, den Status auf "none" ziehen soll und somit Sunprotect funktionieren sollte?
Bei mir ist das am Tag nur der Fall, wenn morgens das erste manuelle "hoch" gesetzt wird. Wenn im laufe des Tages einmal manuell runter und dann wieder manuell hoch (auf 100%) dann bleibt der State "ManuMode" (und SunProtect geht nicht mehr)
Soll das so? Oder mache ich was falsch? Ist das ein Bug? -
@bishop okay, habe die Einstellung gefunden.
Problem ist nur, dass ich teilweise pro Rollo zwei Fenster und zwei Densoren habe.
Kann man auch zwei Sensoren pro Rollo-Aktor hinterlegen?
-
@tobitobsta sagte in Test Adapter shuttercontrol v1.2.x:
"ManuMode"
an dem problem wird im moment rumgerätselt, wie man in diversen postings lesen kann...
-
@kuddel sagte in Test Adapter shuttercontrol v1.2.x:
Kann man auch zwei Sensoren pro Rollo-Aktor hinterlegen?
grundsätzlich mal nicht. wird ohne trixxen nicht lösbar sein. (blockly für beide sensoren, die einen DP füllen.)
-
@negalein Hallo zusammen,
ich werde das Gefühl nicht los, dass die Ursache (mal wieder) an der Implementierung der Homematic Aktoren liegt. Ich hatte das hier schon mal thematisiert.
Die HmIP-Aktoren BROLL und FROLL benutzen den Kanal 3, um den IST-Zustand darzustellen. Die Kanäle 4, 5 und 6 werden benutzt, um SOLL zu setzen. Da Shuttercontrol nur einen Kanal verwenden kann, muss dies logischerweise 4, 5 oder 6 sein (ich verwende im Folgenden mal Kanal 4). Und genau da fängt das Problem an, denn Kanal 4 und Kanal 3 werden in der CCU nicht synchronisiert. Der richtige Wert nach dem Stopp des Rolladens steht deshalb ausschließlich in Kanal 3. In Kanal 4 steht der Sollwert, auch, wenn die Fahrt aus beliebigem Grund vorher gestoppt wurde. Hinzu kommt, dass nach dem Losfahren die Werte in Kanal 3 zufällig wechseln können. Nachdem der Rolladen angehalten hat, dauert es einige Zeit, bis in Kanal 3 der IST-Wert eingetragen wird.
Ich habe mal versucht, das durch ein kleines Skript in den Griff zu bekommen, das einfach den Status des Rolladens überprüft und, sobald dieser angehalten hat, mit einer Verzögerung von einigen Sekunden den Wert aus Kanal 3 in den Kanal 4 schreibt. Das hat jedoch aus nicht nachvollziehbaren Gründen nur teilweise funktioniert, weshalb ich es wieder aufgegeben habe.
Wollte man das Thema zuverlässig lösen, so müssten m.E. in Shuttercontrol zwei Kanäle (IST=3, SOLL=4 oder 5 oder 6) verwendet werden. Wie aufwändig diese Änderung wäre, kann ich natürlich nicht einmal ahnen.
-
@it-veteran
Müsste sich das nicht durch Alias'e umgehen lassen? -
@muchul
Genau durch Alias wurde das Thema hier schon einige male beschrieben. Für den Aktor einen Alias anlegen, indem IST und SOLL Werte des Aktors verknüpft werden und es läuft in shuttercontrol.
Im Prinzip wurde Alias genau für solche Anwendungen geschaffen -
@it-veteran sagte in Test Adapter shuttercontrol v1.2.x:
Ich habe mal versucht, das durch ein kleines Skript in den Griff zu bekommen, das einfach den Status des Rolladens überprüft und, sobald dieser angehalten hat, mit einer Verzögerung von einigen Sekunden den Wert aus Kanal 3 in den Kanal 4 schreibt. Das hat jedoch aus nicht nachvollziehbaren Gründen nur teilweise funktioniert, weshalb ich es wieder aufgegeben habe.
Ja, ging mir auch so.
Bis ich den obigen Thread aufgemacht habe.
Mit dem Alias sind die Werte passend.Leider hat es nichts mit dem aktuellen HM Problem zu tun.
-
@simatec sagte in Test Adapter shuttercontrol v1.2.x:
@muchul
Genau durch Alias wurde das Thema hier schon einige male beschrieben. Für den Aktor einen Alias anlegen, indem IST und SOLL Werte des Aktors verknüpft werden und es läuft in shuttercontrol.
Im Prinzip wurde Alias genau für solche Anwendungen geschaffengibt es hier für ein Beispiel?
Wären dann 2 Datenpunkte in einem oder? -
@bishop sagte in Test Adapter shuttercontrol v1.2.x:
gibt es hier für ein Beispiel?
// Original-Datenpunkt const idOrigin = 'hm-rpc.0.00115A49A5B2BE.4.LEVEL'/*Rollo Wohnzimmer :4 LEVEL*/ // Optional: Status-Datenpunkt, wenn Kommando und Status getrennt. // Bei Nicht-Verwendung Leerstring '' zuweisen const idRead = 'hm-rpc.0.00115A49A5B2BE.3.LEVEL'/*Rollo Wohnzimmer :4 LEVEL*/ // Alias-Datenpunkt const idAlias = 'Rollos.Rollo_Wohnzimmer'; var typeAlias, read, write, nameAlias, role, desc, min, max, unit, states, custom, raum, gewerk; // Folgende kommentieren, wenn keine Änderung der Eigenschaft erforderlich nameAlias = 'Rollo Wohnzimmer'; desc = 'per Script erstellt'; // typeAlias = 'boolean'; // oder 'number' // read = "val < 0 ? -val : 0"; // Erkennung "Aus" --> false erfolgt automatisch // write = "val ? String(1) : String(0)"; // role = 'value'; // min = 0; // nur Zahlen // max = 100; // nur Zahlen // unit = '%'; // nur für Zahlen // states = {0: 'Aus', 1: 'Auto', 2: 'Ein'}; // Zahlen (Multistate) oder Logikwert (z.B. Aus/Ein) custom = {}; // verhindert doppelte Ausführung von history, ... // raum = 'EG_Flur'; // Groß-/Kleinschreibung in der ID beachten ! // gewerk = 'Licht'; // Groß-/Kleinschreibung in der ID beachten ! // Ab hier nichts ändern !! function createAlias(idDst, idSrc, idRd) { if(existsState(idDst)) log(idDst + ' schon vorhanden !', 'warn'); else { var obj = {}; obj.type = 'state'; obj.common = getObject(idSrc).common; obj.common.alias = {}; if(idRd) { obj.common.alias.id = {}; obj.common.alias.id.read = idRd; obj.common.alias.id.write = idSrc; obj.common.read = true; } else obj.common.alias.id = idSrc; if(typeAlias) obj.common.type = typeAlias; if(obj.common.read !== false && read) obj.common.alias.read = read; if(obj.common.write !== false && write) obj.common.alias.write = write; if(nameAlias) obj.common.name = nameAlias; if(role) obj.common.role = role; if(desc) obj.common.desc = desc; if(obj.common.type == 'number') { if(min !== undefined) obj.common.min = min; if(max !== undefined) obj.common.max = max; if(unit) obj.common.unit = unit; } else { if(obj.common.min !== undefined) delete obj.common.min; if(obj.common.max !== undefined) delete obj.common.max; if(obj.common.unit) delete obj.common.unit; } if(states) obj.common.states = states; if(custom && obj.common.custom) obj.common.custom = custom; obj.native = {}; setObject(idDst, obj, function() { if(idRd) setState(idRd, getState(idRd).val, true); else setState(idSrc, getState(idSrc).val, true); }); if(raum && existsObject('enum.rooms.' + raum)) { let obj = getObject('enum.rooms.' + raum) obj.common.members.push(idDst); setObject('enum.rooms.' + raum, obj); } if(gewerk && existsObject('enum.functions.' + gewerk)) { let obj = getObject('enum.functions.' + gewerk) obj.common.members.push(idDst); setObject('enum.functions.' + gewerk, obj); } } } createAlias('alias.0.' + idAlias, idOrigin, idRead); -
-
Hallo zusammen,
erstmal vielen Dank für den tollen Adapter.
Meine Frage hierzu ist jetzt folgende, ich hätte gerne eine Beschattung abhängig von Himmelsrichtung und Lichtsensor.
Da jede Beschattung im Dropdown einen Temperatursensor verlangt habe ich bei Temperatur eine Wert von -50 eingetragen. Damit wollte ich erreichen, dass die Beschattung auch im Winter fährt.
Der Adapter Scheint mit dem Negativen wert aber nichts anfangen zu können. eine Fahrt findet nicht statt.
Auch die Temperaturwerte einfach leer lassen hat nicht funktioniert.
Hat jemand eine Idee?Vielen dank schonmal
-
@harry94
Das war eigentlich mal "oder" verknüpft, ist es aber nicht mehr ist "und" verknüpft ist mir auch aufgefallen.
Ich habe eine sehr niedrige Außentemperatur mit einer hohen Hysterese gewählt, soweit funktioniert es mal.
Vielleicht liegt es am negativen Wert, versuch mal ein Positiven Wert!
