[Neuer Adapter] Homepilot20

[mcm1957]

@pk68

Ev. erstell ein FEATURE REQUEST Issue im adapter Repository. Dort geht das weniger leicht unter als in einem Forumsthread.

Jetzt fehlt nur noch dass der Dev den Adapter in die Repositories aufnhemen lässt

[pk68]

@mcm1957
Ich warte erst mal ab. @homecineplexx hat sich seit ein paar Tagen nicht gemeldet. Er ist vermutlich im Urlaub.

Bin übrigens sehr froh, dass es diesen Adapter gibt. Ohne ihn hätte ich kein ioBroker-System zu Hause. Deswegen stört es mich nicht, wenn es den Adapter nur auf Git gibt.

[homecineplexx]

@pk68 said in [Neuer Adapter] Homepilot20:

@mcm1957
Ich warte erst mal ab. @homecineplexx hat sich seit ein paar Tagen nicht gemeldet. Er ist vermutlich im Urlaub.

Bin übrigens sehr froh, dass es diesen Adapter gibt. Ohne ihn hätte ich kein ioBroker-System zu Hause. Deswegen stört es mich nicht, wenn es den Adapter nur auf Git gibt.

Hallo
ja kann ich machen, aber wie kommst du darauf, dass ich mich ein paar tage nicht gemeldet habe? wo hätte ich mich melden sollen und aufgrund welchen problems???
ich werde mir das mit den gurtwickler anschauen

[pk68]

@homecineplexx
Super, danke für die schnelle Hilfe. Nach dem Update werden die Datenpunkte für den Gurtwicker korrekt angelegt und die Datenpunkte Position und Action scheinen zu funktionieren. Ich schaffe es zeitlich erst morgen den Gurtwickler richtig zu installieren (der liegt momentan auf dem Tisch). Melde mich dann nochmal.
Bitte vergiss die erste Zeile von meinem letzten Post. Die war Müll. Sorry.

[pk68]

@homecineplexx
Der Gurtwickler ist nun installiert. Funktioniert alles wie es soll. Vielen Dank für den schnellen Support.

[Stabilostick]

@homecineplexx

Hi, ich habe von Github die Version 0.0.66 des Adapters installiert. Damit habe ich dann versucht, ein Homepilot Gateway Premium 15001001 mit Software 1.1.19 anzusprechen. Das Gateway-Kennwort ist übrigens nicht gesetzt.

Die Eingabe der IP im Admin führt dann nach dem Instanzstart jedoch zu Fehlern nach dem Schema

"Transmitter sensors -> Cannot connect to Homepilot: {"statusCode":404,"body":"{\"error_description\":\"GET URI not foundhttp://127.0.0.1:5050/v4/devices\",\"error_code\":5002}"}"

Der kommt dann auch für "Scenes", "Read actuator" und "Read sensors" und nichts geht in der Instanz.

Du verwendest zum Auslesen in 0.0.66 fest API-URLs wie z.B.: 'http://' + ip + '/v4/devices?devtype=Actuator'

Die gibt es auf dem Homepilot Gateway Premium Smart so wohl nicht mehr.

Mit dem kleine Hack, statt der IP "<homepilot ip>" den Text "<homepilot ip>/hp" im Admin einzugeben, funktionert das Auslesen und Bedienen von Aktuatoren dann aber. Ist das so schon hier bekannt? Das ergibt dann bei Dir intern

http://<homepilot ip>/hp/devices?devtype=Actuator

und liefert ein wunderbares JSON zurück. Gut, dass Du keinen sanity-Check machst....

Wenn man den Haken bei "Device is Bridge" setzt, gibt es auch keine Warnungen im ioBroker-Log mehr.

Betriebssystem:linux
Architektur:x64
Node.js:v20.18.1
NPM:10.8.2
Admin: v7.1.5
Controller: 7.0.3

Viele Grüße, Thomas

[mcm1957]

@stabilostick

Danke für die Analyse. Pack die Info doch sinnvoller Weise in ein ISSUE beim Adapter rein. Hier geht das wahrscheinlich verloren.

[homecineplexx]

@stabilostick hallo
danke für die Info. nachdem ich leider dieses Gateway nicht habe, kann ich das auch nicht implementieren, außer du hilfst mir da ein wenig.
dazu würde ich dich aber bitten mir ein Ticket im GIT zu schreiben und wir schauen das wir das gemeinsam hinbekommen!

DANKEEEE

[pk68]

@homecineplexx
Hallo, mal eine Frage zu Version 0.0.66 des Adapters. Man kann ja nun die Synczeiten der 4 Kategorien separat einstellen. Ist es ok, dort eine 0 einzutragen, um die Synchronisation zu deaktivieren? Die Linie unter der Zahl wird dann rot gefärbt. Ist das ein Hinweis auf eine fehlerhafte Eingabe und nur die Info das keine Synchronisation mehr stattfindet? Bin kein Javascript-Experte, aber um zu ermitteln, ob eine Abfrage durchgeführt werden soll, wird im Quelltext eine Division mit Rest und der Synczeit als Divisor durchgeführt. Deswegen sollte die Synczeit nicht 0 sein?

[homecineplexx]

@pk68 stimmt, das schau ich mir dann mal an....danke für den hinweis!

[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