IO-Homecontrol Devices über Tahoma Box einbinden

[pc1246]

Hallo Thomas
Die Tahoma Box brauchst du nicht zwingend. Die conexoon tut es auch. Mit ohne Internet habe ich noch nicht probiert kann ich aber mal machen. Heute aber nicht, muss Fußball gucken und sitze gerade noch beim Zahnarzt.
Gruß Christoph

[tpoetschan]

Aaah cooler tipp! Und Somfy Connexxon kann man auch mit diesem Modul ansteuern? Oder gibt es da ein anderes?

Viele Grü

[pc1246]

Moin
Ist das selbe Modul, laeuft bei mr, steht aber hier auch im fred!
Gruss Christoph

[tpoetschan]

Habs inzwischen schon gefunden war wohl etwas blind....
Aber die Offlinefunktion wurde noch nicht ausprobiert, oder? Wie zuverlässig ist denn die Steuerung? Und gibts nicht arge Latenzen bis das Fenster oder der Rolladen reagiert?

Viele Grüße

[pc1246]

Moin
Offline habe ich, wie gesagt, noch nicht probiert! Latenz ist eher vernachlaessigbar! Da es derzeit noch nicht warm ist, habe ich das Biest noch gar nicht eingebunden, nur angelegt und probiert ob es funktioniert! In fhem ist es schon drin nur noch keine Aktivitaeten!
Zum Offline-Betrieb koennen die anderen bestimmt auch etwas betragen, da sich die Tahomas bestimmt gleich verhalten!
Gruss Christoph

P.S.: Offline ist irgendwie auch doof, da ich dann ja das Ganze Internet abklemmen muss. Mal sehen!

[tpoetschan]

Ich bin da leider immer so ein tausendprozentiger ... ich stelle mir bei solchen Restriktionen immer die Frage: Was tun wenn das Internet nicht funktioniert? Ich hätte nämlich gern eine Lösung aus einem Guss :-D Steuerung dann strikt über FHEM und Wandtablet ...

Ich könnte mich über diese IO-Homecontrol Fenster wirklich ärgern ... aber was hilfts. Verbaut sind die schon

[mike3436]

Hat sich schonmal jemand das KLF200 (offenbar neu) angesehen?

Habe ich gerade mal gemacht, und das Gerät ersetzt keine Tahoma (oder Connexon) - jedenfalls ist das nicht dazu gedacht.
Man kann mit dem Ding nur über 10 digitale Eingänge verschiedene Funktionen anstoßen, wie Fenster schließen oder öffnen.
Man kann aber nicht positionieren, und wenn du mehr als 5 Rollos hast, wird es schon wieder schwierig.
Das KLF200 hat zwar einen Netzwerkstecker, der ist aber offiziell für Service, und könnte auch elektrisch anders belegt sein.
Wenn es LAN ist, dann könnte sich dahinter ein Linux verbergen (wie bei der Tahoma Box) und ein findiger Hacker schafft einen Zugriff, aber das ist Wunschdenken.

Die Reaktionszeiten der Tahoma liegen üblicherweise im Sekundenbereich, aber es ist halt eine Internetverbindung mit allen Vor- und Nachteilen.

Gruß Rolf

[Tradestation]

Das Modul mit der Änderung für die korrekte Abarbeitung des Kommandos 'setClosureAndLinearSpeed' wurde eingechecked.

Hallo Rolf,
wenn ich das Kommando 'setClosureAndLinearSpeed' in einem DOIF verwende fährt der Rollladen zwar - aber nicht langsam:

Code Auswählen Erweitern


2017.05.11 01:00:29 3: Rollladen_Wohnzimmer_Tuer: tahoma_applyRequest data={"label":"WohnzimmerTuer RL - Positionieren auf 30 % - iPhone","actions":[{"deviceURL":"io://xxxx-xxxx-xxxx/1234567","commands":[{"name":"setClosureAndLinearSpeed","parameters":[30]}]}]}
sh: 1: lowspeed: not found

Der Befehl dazu sieht folgendermaßen aus:

Code Auswählen Erweitern


define test3 DOIF ([Speed] eq "langsam") (set Rollladen_Wohnzimmer_Tuer setClosureAndLinearSpeed 30,"lowspeed")

In einem AT Kommando gibt es keine Probleme.
Gruß Axel


Lösung: um das Komma beim set-Kommando nicht als Trenner mehrerer Devices zu interpretieren muss eine weitere Klammer gesetzt werden. Somit lautet das Kommando dann richtig:

Code Auswählen Erweitern


define test3 DOIF ([Speed] eq "langsam") ((set Rollladen_Wohnzimmer_Tuer setClosureAndLinearSpeed 30,"lowspeed"))


[mike3436]

Hallo Axel,

wenn ich das Kommando 'setClosureAndLinearSpeed' in einem DOIF verwende fährt der Rollladen zwar - aber nicht langsam

Das liegt nicht am tahoma-Modul sondern an der Befehlssyntax beim set: ein Komma wird hier als Trenner zum Ansteuern mehrerer Devices benutzt (set device1 wert1, device2 wert2).
Ich habe gerade keine Lösung parat, aber das Problem ist bestimmt im Forum beschrieben und gelöst.
Gruß Rolf

[scooty]

Hallo Rolf,

und wieder einmal eine Frage:
Ich habe Velux Elektrofenster im Einsatz, die standardmäßig auch mit einem Regensensor ausgestattet sind.
Dieser ist jedoch nicht als eigenständiger Sensor in Tahoma ersichtlich sondern nur im Elektrofenster direkt "verdrahtet".
Somit hat auch jedes Fenster einen eigenen Regensensor.
Er sorgt bei erkanntem Regen dafür, dass die Fenster
a) falls geöffnet, geschlossen werden
und
b) nicht mehr steuerbar sind (weder über Velux ControlPad noch über Tahoma, die Fenster sind dann nur noch manuell bedienbar)

Bei erkanntem Regen werden die Fenster in der Tahoma-Oberfläche mit einem Ausrufezeichen angezeigt.
Folgender Text erscheint, wenn man auf das Ausrufezeichen klickt:

Ein Sensor hat eine Gefahrensituation für das Produkt erkannt. Es wurde in den Sicherheitsbetrieb mit eingeschränkten Bewegungen geschaltet.

Meine Frage nun:
Besteht die Möglichkeit, den "gesperrten" Status des Fensters irgendwie z.B. als Reading in das FHEM-Device zu bekommen (existiert so ein Sperrmodus eigentlich auch für Markisen o.ä?) ?

Hätte den Charme
a) den eingebauten Regensensor auch für weitere FHEM Aktionen verwenden zu können (ok, nur eingeschränkt, den "gesperrten" Status eines Fensters kann man auch durch manuelle Bedienung des Fensters provozieren)
b) dass man Fahrbefehle (=Funkbefehle) nur dann wirklich absetzt, wenn das Elektrofenster auch im Status "nicht gesperrt" ist (Minimierung der Funklast). Dies muss nicht im Modul erfolgen, durch geeignete devSpec  mit FILTER=... könnte man das bei einem set verwenden.

Meinst Du, so etwas wäre möglich?

Vielen Dank schon mal für's Lesen,
Andreas

[mike3436]

Hallo Andreas,
es gibt für mich zwei Varianten, die möglich sind:
1. es wird ein gesondertes Reading angezeigt
2. es wird nur ein Eintrag in der von mir nicht ausgewerteten Historie benutzt (eher unwahrscheinlich)

Meine Readings beim Somfy Rolladenmotor sind

ClosureState
NameState
OpenClosedState
RSSILevelState
StatusState
devicestate
state

(wobei devicestate und state vom Modul generiert werden)
Hast du vielleicht noch weitere?
Gruß Rolf

[scooty]

Hallo Rolf,

danke für die schnelle Reaktion. 

Freut mich, wenn das wirklich gehen könnte.

Bei den Velux Elektrofenstern gibt es auch nur die Readings, die von Dir genannt wurden.

Viele Grüße,
Andreas

[mike3436]

Hallo Andreas,
ich gehe zwar davon aus, das du dir die Readings bei Regen mal angeschaut hast, aber trotzdem die Frage: ändert sich vielleicht dort etwas in den Inhalten gegenüber dem normalen closed Zustand?
Wenn nicht, dann müsstest du mir mal ein auf tahoma gefiltertes fhem-Log (verbose 4) per PM schicken, mit Zeitraum um die beginnende Regenphase herum.
Gruß Rolf

[Tradestation]

Hallo Rolf, hallo Andreas,
vielleicht kann ich ein paar Informationen zur Diskussion beisteuern:
der Rollladenmotor RS100 io hat noch die zusätzlichen Readings

PriorityLockLevelState                   userLevel2
PriorityLockOriginatorState            user
PriorityLockTimerState                  7650  oder 0

PriorityLockTimerState wechselt zwischen 7650 und 0 wenn man beim Funkwandsender smoove 1 A/M io
für den Rollladen von "manuell" auf "auto" wechselt. Bei Stellung "manuell" ist der Rollladen nicht über FHEM-Kommandos bedienbar.

Gruß Axel

[scooty]

Das Reading

PriorityLockTimerState

habe ich nur bei Elektro-Rolladen, bei denen man jedoch keinerlei manuellen Modus einstellen kann.
Habe auch noch zwei Solar-Rolladen, bei denen existiert das Reading nicht (ebenso kein manueller Modus möglich).

...aber trotzdem die Frage: ändert sich vielleicht dort etwas in den Inhalten gegenüber dem normalen closed Zustand?

Nein, in den Readings ändert sich leider nichts, nur in den Internals (s.u.).

Wenn nicht, dann müsstest du mir mal ein auf tahoma gefiltertes fhem-Log (verbose 4) per PM schicken, mit Zeitraum um die beginnende Regenphase herum.

Habe vor dem Loggen nochmal ein wenig mehr gespielt, ich glaube nun, die Regensensoren geben doch nicht ihren Status an Tahoma weiter:
Bei Regen wird in der Tahoma-Oberfläche nicht direkt das Ausrufezeichen angezeigt und man kann die Fenster immer noch zwischen den Positionen 93% (=Zwangsbelüftung) und 100% ohne Probleme fahren (sorry für die ungenauere Aussage in meinem initialen Beitrag). Erst bei Regen und Positionen unter 93% (=grössere Öffnung) wird der Fahrbefehl vom Fenster nicht ausgeführt und in der Tahoma Oberfläche erscheint das Ausrufezeichen.
In FHEM ändern sich dann die Internals

inExecId finished
inExecState 4

auf

inExecId canceled
inExecState 5

Es scheint mir also so, dass auch Tahoma nicht den Regensensor ausliest, sondern der Zustand des Regensensors nur im Fenster bekannt ist und das Fenster selbst bei einem Fahrbefehl zum grösseren Öffnen eine entsprechende Abbruch-Meldung an Tahoma zurückgibt.

Ich hoffe zwar noch, dass ich mit meiner Interpretation falsch liege, aber alles deutet leider für mich darauf hin, dass Tahoma keine Ahnung hat, dass es regnet 

Andere Interpretationen sind natürlich gerne gesehen. 

Andreas