Beschattung Tag/Nacht/Offen/Gekippt

[Christian Fenzl]

Hallo dirkkleimann, bezüglich deiner Frage per PM:

Den Automatikjalousie-Baustein habe ich bei mir grundsätzlich mit folgender Schaltung implementiert:
http://www.loxwiki.eu/display/LOX/Au...sition+bringen

Tag- und Nacht-Trigger fahren (wie du es schon implementiert hast) mit Cu und Cd die Rollos hoch bzw. runter.

Für die 60%-Position bei Gekippt-Griffstellung könntest du den Beschattungseingang S verwenden (mit entsprechender Einstellung des Parameters Tr=0,6 für die Beschattungslage).
Eine andere Möglichkeit wäre, links an AIp einen zweiten Analogspeicher mit Festwert 60 (%) anzulegen, der durch die Griffstellung "Gekippt" getriggert wird (das hab ich selbst nicht probiert - evt. muss man dem bestehenden Analogspeicher wahlweise Werte vorgeben).

Bei Fenstern verwende ich - anders als bei der Terrassentür - nicht den Eingang Sp (Sicherheitsposition) zum Öffnen, sondern den normalen Eingang Cu. So kann man bei offenem Fenster den Rolladen manuell noch bewegen oder wieder schließen.

Bezüglich Beschattungsposition S bzw. AIp möchte ich noch anmerken, dass Loxone hier komplett falsch rechnet. Die Lage des Rollos ist immer völlig unterschiedlich, abhängig davon, ob der Rolladen von oben oder von unten kommt. Die Tot-Zeiten bei Rolläden hat Loxone beim Implementieren vergessen.

lg, Christian

[svethi]

Da wurden nicht die Totzeiten falsch berechnet. Gerechnet wird hier einfach stumpf die Fahrzeit. Der Motor dreht aber immer gleich, doch je nachdem wie weit oben der Rolladen ist je schneller bewegt er sich da sich die "Rolle" vergrößert, der Umfang mehr wird und dadurch mehr gewickelt wird. Das wird nicht berücksichtigt

[dirkkleimann]

Hi Christian,

super gut, vielen Dank für den Hinweis.
Ich konnte zumindest deine Vorlage schon einmal nachbauen.
Wenn ich nun die Rollos runter lasse, fahren sie beim Öffnen hoch. Das ist schonmal was.
Das Runterfahren klappt zwar noch nicht, aber das hängt mit dem fehlenden Impuls "Abenddämmerung" zusammen?

Alles weitere versuche ich danach.

Zu deinem Eingangssignal I1 Tür offen habe ich aber eine Frage.
In FHEM habe ich die Stati closed/tilted/open(from tilted) nun einmal angepasst auf 0 (closed) und 1 (die anderen). So bekomme ich in deiner Variante Ein/Aus. In deiner Vorlage ist dein Eingang ja ein Taster. Mein VE_UDP von FHEM ein Schieber, auch eigentlich um die korrekten Fensterpositionen anzuzeigen.

Wahrscheinlich banal, aber wie bekommen ich aus den eigentlichen Zuständen 1 eine = 0 (Aus) und für 2 und 3 eine =1 (also EIN).
Ich hab offensichtlich noch Lücken in der Lox-Logik :-)

Gruß
Dirk

[Christian Fenzl]

Die Enocean-Griffe habe ich in FHEM so angelegt:

http://www.loxwiki.eu/display/LOX/FHEM+Basics

Die Programmierung im Wiki ist ja nur ein Beispiel.

In meiner Live-Umgebung sende ich an einen analogen virtuellen Eingang 0=closed, 1=open , 2=tilted.
Das werte ich dann mit einem Statusbaustein aus (siehe Screenshots).

lg, Christian

PS: Ab V8.x gibt es jetzt direkt von Loxone auch einen Fensterbaustein (https://www.loxone.com/dede/kb/fensterueberwachung/). Deswegen würde ich an deiner Stelle gleich die Werte, die FHEM sendet, an die Loxone-Stati anpassen (1=closed, 2=tilted, 3=open). Damit lässt sich der virtuelle Eingang leider nicht mehr so schön mit Logikbausteinen verknüpfen (bei meinen Werten ist 0 zu, und logisch 1 ist ein Offen-Status)

[dirkkleimann]

Ach Mensch klar!!! Der Statusbaustein... Wie einfach das doch alles wäre, wenn man selber mal nachdenken würde :-)

Ich hatte mich bei der Einbindung der Griffe in FHEM ans FHEM-Wiki gehalten und hab die Kommuniktion zwischen FHEM und MS mittels UDP aufgebaut. Anleitung war folgende Seite (darf ich die linken?):

http://www.meintechblog.de/2016/07/5-gruende-zur-erweiterung-deines-fhem-servers-mit-loxone-howto/

Für Newbees wie mich, war das durch die Anleitungen soweit ganz gut umzusetzen. Einzig die Anpassung der Stati in FHEM war notwendig, da der Hoppe SecuSignal ja eingetlich 4 Statis hat (zusätzl. open_from_tilted). Das war aber simple und wurde einfach in der 99_myUtilty... ergänzt.

Ich setze das nachher mal mit dem Statusbaustein um. Dann sollte es auch entsprechend deiner PS:-Anmerkung passen.

Und dann mal heute Abend schauen, ob der Rollo auch wieder runter fährt, wenn die Tür wieder geschlossen wird :-)

Also für den Moment vielen Dank!!!

LG
Dirk

[dirkkleimann]

Leider musste ich meinen Loxberry inkl FHEM neu aufsetzen und oh Wunder: kein Backup :-)

Nun sitze ich bereits seit Freitag hier und grüble mir den Kopf kaputt. Meine Secu-Signal Fenstergriffe senden keine UDP-Befehle, zumindest meine ich dies. Was hab ich bisher getan
UDP im MS angelegt (Port 12345). Hab mal mit der Software "PacketSender" UDPs rausgeschickt. Die kommen an.

In FHEM sieht es wie folgt aus.
In der config-Datei ist folgender Eintrag:
define OpenClosedToLoxone notify .*open|closed|tilted) OpenClosedToLoxone("$NAME")}

Die myUtily hat folgende Einträge:
# Enter you functions below _this_ line.

use IO::Socket;

#UDP Befehle senden
sub UDP_Msg($$$)
{
my ($dest,$port,$cmd) = @_;
my $sock = IO::Socket::INET->new(
Proto => 'udp',
PeerPort => $port,
PeerAddr => $dest
) or die "Could not create socket: $!\n";
$sock->send($cmd) or die "Send error: $!\n";
return "send $cmd";
}

#OpenClosedToLoxone
#device
#1 state(0,1)
#2 alive(1-0)
#3 battery(0,1)
sub OpenClosedToLoxone($)
{
my ($device) = @_;
my $state = ReadingsVal("$device","state","-1");
if ($state eq "closed") {
$state = "0";
}
if ($state eq "open") {
$state = "1";
}
if ($state eq "tilted") {
$state = "2";
}
if ($state eq "open_from_tilted") {
$state = "3";
}
my $alive = ReadingsVal("$device","alive","-1");
if ($alive eq "yes") {
$alive = "1";
}
if ($alive eq "no") {
$alive = "0";
}
my $battery = ReadingsVal("$device","battery","-1");
if ($battery eq "ok") {
$battery = "1";
}
if ($battery eq "low") {
$battery = "0";
}
my $sabotage = ReadingsVal("$device","sabotageError","-1");
if ($sabotage eq "on") {
$sabotage = "1";
}
if ($sabotage eq "off") {
$sabotage = "0";
}
UDP_Msg("192.168.178.240" , "12345" , "$device: $state $alive $battery $sabotage");
}
1;

Ich finde den Fehler einfach nicht. Die Geräte sind angelegt. Status wird im FHEM angezeigt. Nur die Anbindung an den MS klappt nicht.
Vielleicht sieht jemand den Fehler. Ich verzweifle langsam :-(

[Christian Fenzl]

Du musst mal checken, ob die Send-Routine überhaupt aufgerufen wird, oder nichts beim MS ankommt.

Mach Statements
print STDERR "Trace";
in den Code und schau, ob das in einem Log ankommt.
Ich weiß nicht, welches Log (FHEM oder syslog)

[dirkkleimann]

Hi Christian,

danke das du unterstützt. Den Print-Befehl dann in der Konsole von putty eingeben oder in eine der FHEM Dateien? Heute morgen konnte ich kurz prüfen, in der Konsole der FHEM Weboberfläche wurde der Befehl nicht akzeptiert.

Was mich zusätzlich etwas verwundert:
Die Def-Befehle etc, welche in der FHEM.cfg über die Weboberfläche einzusehen sind, finden sich in der Putty-Konsole nicht, wenn ich per nano fhem.cfg die Config öffne. Dort stehen "nur" die ursprünglichen Daten drin. Ist das immer so?

Außerdem habe ich mich gefragt, ob der Port eine Rolle spielen kann, da Loxberry über Port 80 kommuniert.Mein gesetzter in FHEM für die UDP aber 12345 (hab unterschiedliche durchporbiert)

[Christian Fenzl]

Das ist Perl und ist fürs sub OpenClosed gedacht, um zu sehen, ob die Funktion überhaupt aufgerufen wird.

Der LoxBerry-Port hat nichts mit dem UDP-Port zu tun.

Wie hast du’s denn vorher eingerichtet, wo es funktioniert hat?

[dirkkleimann]

Nachdem es lange funktioniert hat und ich nicht mehr weiß, was im Detail damals nicht geklappt hat, habe ich neulich festgestellt, dass die Rolläden beim Betätigen der Fenstergriffe nicht mehr auffahren. Also einmal gecheckt: -> Altes Problem, die Signale kommen nicht an.

FHEM läuft als Plugin auf dem Loxberry. Das EcOcean-Modul ist intialisiert, die Griffe sind da und zeigen den korrekten Status an.
Den Log-Files entnehme ich, dass auch ein SEND-Befehl ausgeführt wird, und zwar über Port 7000.

Im MS-Monitor kommt aber nichts an. Der VI horcht auf 7000, es ist keine IP eingegeben (so hatte ich es auch vorher).
Auf 7002 sendet zB der MI Roboter über das entsprechende PlugIn, das kommt an.

Welche Aspekte könnte ich noch prüfen.
Der Loxberry läuft auf 1.2.xx (weiß ich gerade nicht). FHEM ist auf aktuellem Stand.

[Christian Fenzl]

Prüf in Loxone, ob _irgendetwas anderes_ (egal ob ein/ausgehend, UDP oder sonst was) den Port 7000 benutzt.

Wechsle den Port auf zb 23456 und schau, ob das ankommt.

[dirkkleimann]

Das werde ich heute abend mal evaluieren!

[dirkkleimann]

Vielleicht rührt das Problem von anderer Stelle her...
Ich hab in. FHEM versucht die Ports zu ändern. Das klappt ja gar nicht. Bekomme folgende Meldung zurück:

Cannot open /opt/loxberry/config/plugins/fhem/fhem.cfg: Read-only file system

Da ich zeitgleich auch das "Problem" habe, dass ich den Loxberry nicht updaten kann, könnte ja hier ein kausaler Zusammenhang bestehen - den ich nicht beheben vermag...

[svethi]

Da ist Dein Filesystem defekt. Mit ziemlicher Sicherheit die SD-Karte kaputt

[dirkkleimann]

NEIN!!!! Bitte nicht
Gibt es keine bessere Lösung *hust*