[Neuer Adapter] Homepilot20
-
Super, danke für die Anpassung. Aus meiner Sicht funktioniert alles wie es soll.
-
@pk68 BITTESCHÖN und Danke für die Inputs.
oft ist man auch ein bissl Betriebsblind
-
Erst einmal vielen Dank für den super Adapter!!
Funktioniert hervorragend (für meine rohrmotoren).Ich hab auch kein Problem,
Sondern nur zwei Fragen dazu
Etwas kniffelig wird es aber immer, wenn es um set und get der Position geht.
Rademacher hat dies ja in einem Endpunkt zusammen gefasst.
Über Vor- und Nachteile müssten wir nicht sprechen.
Aber wäre ein gesonderter nur lesender "get"-Endpunkt mit den aktuellen Werten nicht toll?
Die OberflächenWidgets unterstützen dies ja meistens...Wahrscheinlich gibt es diesen über die Schnittstelle nicht?
Jetzt wäre ich geneigt, diesen "virtuell" zu bauen.
Aber das ist auch bissel umständlich für die Anzahl der Rohrmotoren.
Zentral ist ja doch immer schöner...Daher meine Frage: wäre es ggf. sinnvoll einen virtuellen "get"-Endpunkt im Adapter einzubauen, welcher sich aus dem Positionsendpunkt ableitet?
Man würde vielleicht noch einen zusätzlichen technischen internen Endpunkt haben, welchen man selbst einmal administrativ setzen muss - um die Zeit einzustellen, die die spezifische Rollo für den 0->100% lauf braucht.
Und der virtuelle Punkt kann dann aus der Differenz der Position und der Zeit die "virtuelle" Position berechnen.
Um während des Laufes berechnete Zwischenpositionen zu haben und anzeigen zu können.Das war die eine Frage
Die Zweite kommt auf, wenn man die Endpunkte Richtung Matter-Bridge weiterreichen möchte.
Es gibt ein Autoimport vom Matteradapter, welches aber nicht funktioniert, weil die Endpunkte anders als erwartet heißen bzw. es zwei "level"-Endpunkte gibt (der invertet-Endpunkt ist wohl das Problem...).Es gibt wohl über den "Device-Adapter" eine eindeutige, übergreifende Endpunktbeschriftung, als auch Aliaserstellung - ein guter Workaround - Bleibt aber ein Workaround.
Die Endpunkte sehen dort wiefolgt aus:
Zumal man hier für Stop, Open, Close boolean-Endpunkte erwartet werden.
Hier muss man also bei jedem Endpunkt Konvertierungsfunktionen angeben - kann auch der Adapter - immer noch ein guter Workaround.Ich fragte mich hier nur, ob es nicht ggf. sinnvoller wäre, die Endpunkte von Rademacher automatisch vom Adapter in dieses "Format" konvertieren zu lassen, bevor wir alle (bzw. jene die dies nutzen wollen) das sehr oft für jeden einzelnen Endpunkt machen müssten?
Also ggf. einzelne zusätzliche Endpunkte in einem zusätzlichen Unterordner je Gerät? Oder so?Soweit meine Fragen - okay, halbe Featurerequests
VG
BB -
@bluebook Ich verstehe Deine erste Frage vermutlich nicht richtig, aber: Wenn ich einen Rollladen auf 30% schicke, dann wäre doch sofort nach der Fahrt der set und der virtuelle get-Datenpunkt wieder gleich auf 30%. Warum sollte da bei get jemals was Anderes angezeigt werden?
Gruss, Jürgen
-
@wildbill Ja, das stimmt.
Es geht wirklich nur um die Differenz während der Fahrt.Ich mach mal ein Beispiel
Die Fahrt auf 0 auf 100% dauert 5 Sek. und wir fahren von 0 auf 100.
Bei Rademacher steht sofort 100 drin. Nach der ersten Sekunde, obwohl wir ja noch bei 0 stehen.
Mit dem virtuellen Punkt wären dann grob:
nach 1 Sek. 20%
nach 2 Sek. 40%
nach 3 Sek. 60%
nach 4 Sek. 80%
nach 5 Sek. 100%Also ja, nach der Fahrt sind die Punkte gleich, aber während der Fahrt hätte man die berechneten Werte zur Anzeige
-
@bluebook said in [Neuer Adapter] Homepilot20:
nach 1 Sek. 20%
nach 2 Sek. 40%
nach 3 Sek. 60%und was genau bringt einem das? da kannst du dir aber auch gern selbst einen virtuellen datenpunkt machen und dir das selbst berechnen
-
@bluebook Vielleicht beschreibst Du nochmals genau, was Du Dir davon erhoffst. Du hattest als Beispiel Widgets genannt, also irgendeine Visualisierung. Wenn ich Dich richtig verstehe, dann willst Du da beispielsweise 30% eintragen und das Widget soll für die paar Sekunden Fahrt dann den möglichst EXAKTEN Stand anzeigen? Aber wozu? Ob da jetzt gleich 30% stehen, oder nacheinander im Paar-Sekundentakt 10,20,30 ist doch eigentlich nur Spielerei?! Wenn der Rollladen den gewünschten Wert nicht erreicht, weil er beispielsweise hängengeblieben ist, dann siehst Du den exakten Wert, wo er steht, und im Objektbaum geht der Datenpunkt hasErrors beim jeweiligen Gerät auf einen Wert ungleich 0.
Gruss, Jürgen
-
ja, okay, es ist soviel "Spielerei", dass es anscheinend einige nicht als "wichtig" erachten?
Ja, natürlich, ist das schon "Liebhaberei", oder so... bin ich ja bei Dir....Aber genau in dem Punkt, weicht halt die Rolladensteuerung von der Norm ab.
Und nenne es pingelig, aber mich stört es, wenn ich es auf meinem Tablet bediene und "plomm" 100% - nneee...- kann man natürlich auch anders sehen. Aber deswegen hatte ich nach einer Lösung gesucht....
Die beschriebene ist (finde ich) akzeptabel und löst das Problem.
Entweder baut jeder es selbst, je Endpunkt - das wäre dann eine selbstgebaute Lösung und lokal, dann (bei mir wohl) ein ziemliches copy&paste-Massaker und kein anderer hat was davon...Daher dachte ich, frag ich doch mal nett und vielleicht empfindet ein Entwickler das ja auch so und hat Lust das mit einzubauen? - Fragen kostet ja nichts, oder?
Der zweite Punkt von oben, mit den zusätzlichen "genormten" Datenpunkten, wäre mir eigentlich auch der Wichtigere oder wahrscheinlich auch der Sinnvollere - wie man es sehen mag :}
Schöne Ostern
-
@bluebook Als nicht wichtig hat es ja keiner bezeichnet. Was dem einen fehlt, juckt den anderen halt überhaupt nicht. Ich habe grad mal geschaut, wie es sich beim direkten Bedienen mit der Bridge verhält. Selbst da sehe ich bei meinem „langsamsten“ Rollladen nur 2-3 Zwischenschritte auftauchen als aktuellen Stand, wenn ich von 0 auf 100 fahre oder andersrum. Vermutlich kommen also schon hardwareseitig gar nicht so viele Daten an, wie Du gerne hättest. Selbst wenn der Adapter hier im Sekundentakt pollen würde, bekommt er ja maximal nur so viel, wie die Bridge bekommt/anzeigt.
Gruss, Jürgen
-
@wildbill ohja, guter Punkt, stimmt Performance ... per Matter wird das schwierig. Danke für´s nachschauen/testen.
Die zwei Fragen stehen bei mir aber nicht im Zusammenhang, auch wenn man dies natürlich meinen könnte.
Also das mit den "Zwischenständen" wäre bei mir "nur" zwischen iobroker und vis.
Ich hatte bisher das Gefühl, dass der relativ schnell aktualisiert, oder?Viele Grüße
BB -
@bluebook das mit der VIs und diesen Zwischenschritten macht aus meiner Sicht ehrlich gesagt überhaupt keinen Sinn, vor allem weil defaultmäßig für Actuator 4 Sekunden polling eingestellt ist. klar könntest du es auf 1 Sekunde stellen aber auch da halte ich das für komplett übertrieben. Sowas kann man, wenn es wirklich haben möchte auch generisch im ioBroker nachbilden und daher werde ich sowas nicht einbauen
-
@homecineplexx
Ich glaube du hast Recht - da war der Wunsch eher der Vater des Gedankens und irgendwie dachte ich auch, dass vis und iobroker enger gekoppelt sind. Mit Polling ist der Ansatz nicht so sinnvoll - wahrscheinlich müsste man sich sonst überlegen, es eher clientseitig zu lösen....
Ich glaub ich stell die Idee erst einmal wieder in die Ecke, bis es mich dann in 4-8 Wochen doch wieder zu sehr nervt
Danke für s mit diskutieren. Jetzt bin ich wieder etwas schlauerDarf ich trotzdem noch einmal den zweiten Punkt ansprechen?
Gibt es einen "einfachen" Weg die Endpunkte der Rademacheraktoren in den Aliasadapter "passend" erstellt zu bekommen, oder direkt in matter-Adapter?
Ich sehe im Moment nur den komplett manuellen Weg.
Wäre es nicht cool, wenn das besser unterstützt wird?VG
BB
