UPDATE 31.10.: Amazon Alexa - ioBroker Skill läuft aus ?

[Uwe Clement]

@StrathCole

Ich habe es nun so gelöst, erstelle mir einen eigenen Datenpunkt:

// Markise 1:
on({id: "tahoma.0.devices.10.states.moving", change: 'any'}, function (obj) { 
    var value = obj.state.val;
    var oldValue = obj.oldState.val;
    if (value == 0 && oldValue == 1) {
        setState(state_position_markise1, "Auf");        
    } else if (value == 0 && oldValue == 2) {
        setState(state_position_markise1, "Zu");
    } else {
        setState(state_position_markise1, "???");
    }
});  

[StrathCole]

@Uwe-Clement Hm, den Sinn verstehe ich ehrlich gesagt nicht. Für den Status nur "auf" oder "zu" ohne die genaue Position gibt es doch eigentlich tahoma.0.devices.xxxxx.states.core:OpenClosedState.

[Uwe Clement]

@StrathCole

Ich glaube wir reden einander vorbei bzw. unser Unterschied ist "IO" oder "RTS". Ich habe "RTS" und da habe ich fast gar keine Datenpunkte. RTS ist ja wohl nur ein Protokoll in eine Richtung und empfängt nicht.

Natürlich hätte ich auch gerne die genaue Positionsangabe. Aber immerhin zu wissen, ob auf oder zu, ist schon einmal viel wert. Und out-of-the-box sehe ich diesen Status nicht in meinem Adapter bzw. in meinen Datenpunkten.

Habe ich einen Denkfehler oder liegt es an "IO" bzw. "RTS"?

[StrathCole]

@Uwe-Clement Ah, okay. RTS ist natürlich was anderes. Wenn du dich auf tahomalink.com einloggst, siehst du da denn den Status?

[Uwe Clement]

@StrathCole nein, da sehe ich auch keinen Status

[StrathCole]

@Uwe-Clement Okay, dann kriege ich es mit dem Adapter leider auch nicht hin.

[Uwe Clement]

@StrathCole Passt.

Immerhin kann ich meine Markisen über Iobroker/Alexa/App,..... hoch und runterfahren und ich kann noch abfragen, ob Markise ein- oder ausgefahren ist.

Es könnte mehr sein, aber auch deutlich weniger. Bin zufrieden!

Danke an alle die an dem Adapter beteiligt sind/waren!!

[9_Mad-Max_5]

Hi,

Wäre es nicht eine Idee, wenn du intern eine prozentuale Umsetzung machst @Uwe-Clement .
Ich weiß nicht ideal aber wäre ein bisschen was.
Einfach einmal hochfahren und runterfahren und schauen in wie viele sinnvolle schritte du es aufteilen kannst.
Natürlich wird es dann etwas komplizierter, wenn du wieder die Rollos mit dem normalen Handsender benutzt.
Ich weiß nicht ideal aber immerhin ein bisschen was oder?

[Uwe Clement]

@9_Mad-Max_5

Der Handsender verschwindet, der ist nicht das Problem Die Leute sollen über Alexa steuern (auf der Terrasse, oder eigentlich überall steht ein Echogerät).

Aber wie meinst Du das? Ich kann mir nur vorstellen, dass ich noch was optimieren kann wenn ich die Zeit auswerte?!

Wie meinst Du dies genau?

[StrathCole]

@Uwe-Clement sagte in Anfrage Tahoma/Somfy IO Adapter:

Aber wie meinst Du das? Ich kann mir nur vorstellen, dass ich noch was optimieren kann wenn ich die Zeit auswerte?!

Ja, das wäre die einzige Möglichkeit. Für jeden Rollladen messen, wie lange das Auf- und Zufahren dauert und daraus sowohl die Befehle bei %-Steuerung ableiten (nach X Sekunden STOPP senden) bzw. aus der Laufdauer die % errechnen.

[Uwe Clement]

@StrathCole werde ich die nächsten Tage ausprobieren. Wird aber sicherlich funktionieren.

[michihorn]

Hallo ich teste den Adapter nun auch, mir fällt auf das in der aktuellen Version kein State mehr zu tahoma.0.devices.xxxxxx.core:DeploymentState gegeben wird. In alten Versionen stand noch der Status 100% oder 0% bei mir steht nur noch 0%, weiterhin ist mir aufgefallen, obwohl es keine Verbindung zu Somfy geben konnte hat der Adapter behauptet er ist verbunden.
Ich hätte gerne wieder die Status angaben über die Position drin.
LG Micha
Top Job, Respekt

Edit: habe gerade ein Downgrad auf 3.0 gemacht dan klappt die Statusangabe noch.

[9_Mad-Max_5]

@Uwe-Clement
Ja genau so wie @StrathCole es gesagt hat. Aus der Laufzeit des Rollladens einen Prozentwert ableiten.
Da ich die RTS nicht kenne kann ich da nicht all zu viel helfen.
Aber wenn der wert von den Endanschlägen gemeldet wird könnte man diesen Wert zur Korrektur benutzen.
Also wenn sie am Tag wieder ganz oben sind alles auf 0% setzten. Ich denke damit hasst du immerhin eine modulare Steuerung.
Natürlich könnte man sich auch überlegen, ob man sowas in den Adapter selbst eingebettet bekommt und der Nutzer die Rollladenlaufzeit angibt.
Aber der Adapter ist ja schon sehr gut, auch wenn ich ihn noch nicht benutzen kann

[freeman6555]

Hallo zusammen, mein erster Post in diesem Forum

Ich benutzte den Tahoma Adapter schon seit einigen Wochen, ich habe jedoch beim auffahren meiner Rollos (über den ShutterControl Adapter) jeden morgen einige Fehlermeldungen und nicht aufgefahrene Rollos.
Hier mal die Meldung:

tahoma.0	2020-05-06 08:33:51.565	warn	(12861) error during tahomalink request: Error: connect ENETUNREACH 178.32.15.131:443 - Local (0.0.0.0:0), request path: events/e7b61f8d-ac10-3401-3e31-1afecfc4832e/fetch with payload:{}
tahoma.0	2020-05-06 07:00:10.622	warn	(12861) Body: {"errorCode":"TOO_MANY_OPERATIONS_IN_PROGRESS","error":"Server busy, please try again later. (Too many executions)"}
tahoma.0	2020-05-06 07:00:10.621	warn	(12861) Response: {"statusCode":429,"body":{"errorCode":"TOO_MANY_OPERATIONS_IN_PROGRESS","error":"Server busy, please try again later. (Too many executions)"},"headers":{"date":"Wed, 06 May 2020 05:
tahoma.0	2020-05-06 07:00:10.619	warn	(12861) error during tahomalink request: null, request path: exec/apply with payload:{"label":"Küche_Links.states.core:ClosureState - Positioniere auf 0 % - ioBroker","actions":[{"deviceURL":"io://12

Mir ist schon bewusst was diese meldungen bedeuten, aber was kann ich dagegen tun? Ich habe schon versucht die Rollos mit größerem Abstand voneinander hochfahren zu lassen (7 Stück mit 4 sec Abstand) und den Abfrageintervall habe ich auch schon auf bis zu 30000 geändert (wobei mir nicht klar ist was das für ein Wert ist, sollen das Millisekunden sein?) Aber es bleiben immer Rollos unten.
Interessant ist auch, dass die Rollos Abends oder Fehlermeldunger herunterfahren.

Vor der Tahoma Adapter hatte ich die Lösung mit dem Homebridge Adapter und Tahoma Plugin, dort war das kein Problem... Vielleicht werden da weniger Werte übermittelt.

Hat jemand eine Idee?

[StrathCole]

@freeman6555 Vielleicht sendet der ShutterControl Adapter für jeden Rollladen einen eigenen Befehl. Der Tahoma-Adapter fasst Befehle, die innerhalb von 500ms kommen in einen Befehl zusammen, damit eben nicht zu viel parallel läuft. Ich nutze ShutterControl nicht, kann daher nichts dazu sagen, wie dort Befehle gesendet werden.

[freeman6555]

@StrathCole Im ShutterControl werden die states.core:ClosureState bei den Tahoma Objekten verknüpft, diese werden dann nach Sonnenaufgang +/- Verzögerung aufgefahren, im Moment sollen im EG die 7 Rollos um 7 auffahren, 2 Rollos im OG um 9. Wenn die Zeit für´s EG erreicht wird, setzt ShutterControl alle 2 sek einen Rollo State (diese 2 sek sind einstellbar, damit nicht alle auf einmal fahren), bis zum 5. Rollo fahren alle, beim 6. wird dann dieser Fehler angezeigt, auch die OG Rollos um 9 fahren nicht. Es muss erst der Tahoma Adapter neu gestartet werden, dass Rollos wieder verfahrbar sind.
Warum dann das zufahren im OG um 18 und EG um ca. 21 funktioniert ist mir auch ein Rätsel, die abarbeitung erfolgt hier in der gleichen wie beim auffahren Morgens.
Diese Einstellung von ShutterControl hat bis auf minimal änderungen bei der Homebridge Variante super funktioniert.

[freeman6555]

@StrathCole

Ich habe gestern mal diese 2 sekunden Abstand zwischen den Rollos (also wenn die Rollos um 7 hochfahren soll, fängt der 1. um 7:00:00 an, der 2. um 7:00:02, der 3. um 7:00:04, usw. bis alle Rollos oben sind) auf 0 gestellt, also alle fahren gleichzeitig hoch, und siehe da, keine Fehlermeldungen vom Tahoma Adapter. Auch die Rollos im OG fahren um 9 dann hoch, der Adapter hatte ja nix zu meckern.
Weißt du auf wie viele Anfragen der Somfy Server den Adapter begrenzt oder ob das noch ein Adapter Fehler sein kann? Ich denke mal, weil ich ja schon einige Geräte habe und somit auch viele Anfragen und Werte übertragen werden, dass das einfach zu viel ist wenn die Rollos mit Zeitverzögerung gefahren werden.

[StrathCole]

@freeman6555 sagte in Anfrage Tahoma/Somfy IO Adapter:

alle 2 sek einen Rollo State (diese 2 sek sind einstellbar, damit nicht alle auf einmal fahren),

Den Sinn verstehe ich nicht.

@freeman6555 sagte in Anfrage Tahoma/Somfy IO Adapter:

und siehe da, keine Fehlermeldungen vom Tahoma Adapter.

War zu erwarten, denn es ist dann nur ein Job, der bei Tahoma läuft.

@freeman6555 sagte in Anfrage Tahoma/Somfy IO Adapter:

Weißt du auf wie viele Anfragen der Somfy Server den Adapter begrenzt oder ob das noch ein Adapter Fehler sein kann?

Das weiß ich leider nicht. Ich fahre die Rollläden immer entweder gleichzeitig oder mit mehr Abstand.

[Uwe Clement]

Habe das Problem, dass mittlerweilen die "states.moving" nicht mehr vorhanden sind:

tahoma.0.devices.10.states.moving

Warum wurden diese Datenpunkte entfernt?

[Joe Bogger]

Apple Home Somfy Jalousiesteuerung.
Nach langem Versuchen hier die Lösung zur Steuerung einschl. Lüftungsstellungen. Es brauch keiner Script oder zusätzlicher Adapter. Sie Somfy kennen nur eine Lüftungsstellung von 0 - 100% das nicht auf die Home App -90 bis +90° passt. Daher hier ein Mapping.
HomeKit Minimum: 0
HomeKit Maximum: 100
ioBroker Minimum: 0
ioBroker Maximum: 100

Bei den TargetVerticalTiltAngle musste auch ein Mapping her, da die Werte aus der Home App nicht übergeben wurden:
javascript.0.tahoma.devices.Büro Fenster.states.core:SlateOrientationState -> tahoma.0.devices.Büro_Fenster.states.core:SlateOrientationState

Funktioniert nun super und kann beliebig in Home App Szenen und Automationen eingebunden werden.

Vielen Dank für den Tahoma Adapter!!