[Neuer Adapter] Homepilot20

[homecineplexx]

@pk68 so, ich hab mir das angeschaut und so wie du das schreibst stimmt es natürlich nicht.
man kann zwar bei den 4 Sync-Zeiten eine 0 eintragen, bleibt man aber länger mit der Maus drüber, kommt ein Text: "Wert muss größer als oder gleich 1 sein"
Speichert man dennoch so eine 0, ist auch kein Thema, denn im Code wird darauf abgefragt und sollte eine SyncZeit 0 oder null sein, wird auf den default gesetzt.

Keine Ahnung welchen Code du meinst mit: "wird im Quelltext eine Division mit Rest und der Synczeit als Divisor durchgeführt"

lg

[pk68]

@homecineplexx sagte in [Neuer Adapter] Homepilot20:

@pk68 so, ich hab mir das angeschaut und so wie du das schreibst stimmt es natürlich nicht.
man kann zwar bei den 4 Sync-Zeiten eine 0 eintragen, bleibt man aber länger mit der Maus drüber, kommt ein Text: "Wert muss größer als oder gleich 1 sein"

Ich will nicht streiten. Den Hilfetext beim Mouseover habe ich nicht bemerkt.

Speichert man dennoch so eine 0, ist auch kein Thema, denn im Code wird darauf abgefragt und sollte eine SyncZeit 0 oder null sein, wird auf den default gesetzt.

Wenn man die Sync-Zeiten ändert, dann werden ja die Sync-Zeiten im Log ausgegeben.
Lässt man das Feld für die Sync-Zeit leer, dann wird die Defaultzeit verwendet.
Trägt man ein 0 ein, wird die 0 übernommen.

2025-01-09 16:28:41.774 - info: homepilot20.0 (900907) starting. Version 0.0.66 (non-npm: homecineplexx/ioBroker.homepilot20) in /opt/iobroker/node_modules/iobroker.homepilot20, node: v20.18.1, js-controller: 7.0.6
2025-01-09 16:28:41.802 - info: homepilot20.0 (900907) Homepilot station and ioBroker synchronize actuators every 4s
2025-01-09 16:28:41.803 - info: homepilot20.0 (900907) Homepilot station and ioBroker synchronize sensors every 0s
2025-01-09 16:28:41.804 - info: homepilot20.0 (900907) Homepilot station and ioBroker synchronize transmitters every 21s
2025-01-09 16:28:41.805 - info: homepilot20.0 (900907) Homepilot station and ioBroker synchronize scenes every 23s

Die 0 ist für den Code eine gültige Zahl?
main.js

sync_sensors = (adapter.config.sync_sensors === undefined || adapter.config.sync_sensors.length === 0) ? 3 : parseInt(adapter.config.sync_sensors,10);
adapter.log.info('Homepilot station and ioBroker synchronize sensors every ' + sync_sensors + 's');

Wenn man beim Adapter die Protokollebene auf Debug umstellt, werden ja die Abfragen mitgeloggt.
Synctime sensors: 3s

2025-01-09 16:31:28.873 - debug: homepilot20.0 (901024) reading homepilot sensor JSON ...
2025-01-09 16:31:28.896 - debug: homepilot20.0 (901024) Homepilot sensor data: {
"response": "get_meters",
"meters": []
}
2025-01-09 16:31:28.914 - debug: homepilot20.0 (901024) finished reading Homepilot additional Sensor
2025-01-09 16:31:28.915 - debug: homepilot20.0 (901024) Finished reading Homepilot sensor data
2025-01-09 16:31:31.876 - debug: homepilot20.0 (901024) reading homepilot sensor JSON ...
2025-01-09 16:31:31.886 - debug: homepilot20.0 (901024) Homepilot sensor data: {
"response": "get_meters",
"meters": []
}
2025-01-09 16:31:31.901 - debug: homepilot20.0 (901024) finished reading Homepilot additional Sensor
2025-01-09 16:31:31.901 - debug: homepilot20.0 (901024) Finished reading Homepilot sensor data
2025-01-09 16:31:34.878 - debug: homepilot20.0 (901024) reading homepilot sensor JSON ...
2025-01-09 16:31:34.890 - debug: homepilot20.0 (901024) Homepilot sensor data: {
"response": "get_meters",
"meters": []
}
2025-01-09 16:31:34.911 - debug: homepilot20.0 (901024) finished reading Homepilot additional Sensor
2025-01-09 16:31:34.912 - debug: homepilot20.0 (901024) Finished reading Homepilot sensor data

Bei Synctime sensors 0s erfolgt keine Ausgabe im Log, also keine Abfrage der Sensordaten?

Keine Ahnung welchen Code du meinst mit: "wird im Quelltext eine Division mit Rest und der Synczeit als Divisor durchgeführt"

Den Code den ich meine ist in der main.js Zeile 452 (hier Zeile 9):

	callMainInterval = setInterval( async function() {
		try{			
			if (isRunning) {				
				return;
			}
			isRunning = true;		
			counter++;	
			await Measure('station.Overall_Sync_Time', async () => {					
				if (counter % sync_sensors === 0){				
					adapter.log.debug('reading homepilot sensor JSON ...');
					await Measure('station.Sync_Sensors_Time', async () => {						
						await readSensor('http://' + ip + '/v4/devices?devtype=Sensor');
					});
				}

Gruß

[homecineplexx]

@pk68 du hast vollkommen recht. sorry, ich hab einfach drüber gelesen.
ich hab's jetzt in der 0.0.67er Version geändert und so eingebaut, dass wenn eine SyncTime == 0 ist, wird sie aufs default gesetzt.

DANKE

[pk68]

@homecineplexx
Nur so als Idee. Man lässt die 0 als gültige Eingabe zu und 0 heißt dann keine Abfrage der Daten.

Bei meiner überschaubaren Rademacher-Installation brauchen nur die Aktoren abgefragt werden. Die anderen drei Abfragen sind nicht nötig. Da wäre die Möglichkeit, diese abzuschalten, sinnvoll. Im Gegenzug könnte man mit der Sync-Zeit für die Aktoren heruntergehen.

[homecineplexx]

@pk68 guter Input - DANKE. hab ich mit der 0.0.68er umgebaut. Probiers mal aus

lg

[pk68]

@homecineplexx

Super, danke für die Anpassung. Aus meiner Sicht funktioniert alles wie es soll.

[homecineplexx]

@pk68 BITTESCHÖN und Danke für die Inputs.
oft ist man auch ein bissl Betriebsblind

[BlueBook]

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

[Wildbill]

@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

[BlueBook]

@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

[homecineplexx]

@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

[Wildbill]

@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

[BlueBook]

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

[Wildbill]

@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

[BlueBook]

@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

[homecineplexx]

@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

[BlueBook]

@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 schlauer

Darf 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