Ankündigung

**Brick** · 17.04.2019, 06:27

Ohne mir jetzt deine Logik genau angesehen zu haben.. nur mal so als Idee:
Die Lampen wie du es gemacht hast auf ODER Bausteine legen. Und diese schalten im Prinzip gleich direkt die Heizung auf Komfort/
Nachtabsenkung. Eine Sperre dazwischen, die je nach ZSU freigibt oder eben nicht.
Das ganze wird dann zb. 15 minütlich getriggert (So kann auch mal einer kurz das Licht einschalten ohne das gleich umgestellt wird)
Eine weitere Sperre noch für Tag/Nacht... damit das Tagsüber nicht genutzt wird..

Gruß Martin

**MrIcemanLE** · 17.04.2019, 10:42

Was Martin schon angedeutet hat, würde ich dir auch empfehlen. Schau dir mal den LBS "Sperre" an. Ein "UND" sorgt immer für einen Trigger an den nachfolgenden Bausteinen, egal welcher Eingang sich ändert.

Was willst du mit dem "Entprellen" erreichen? Hier gehen dir innerhalb der 3s alle Telegramme verloren. Vielleicht hilft hier auch der Watchdog-LBS weiter. Dieser überwacht ob eine Bedingung lange genug vorherrscht: Ist also das Licht für 30 Minuten an, dann wird der Ausgang auf 1 gesetzt.

Am Ende würde ich einen SBC (SendByChange remanent) einsetzen um unnötiges Schreiben auf den Bus oder den Aktor zu vermeiden.

Mir hat es geholfen die Logik immer mit einer Art "Impuls" bzw. "Trigger" gedanklich durchzuspielen. Jedes KO liefert ja letztendlich auch nur einmal pro Ereignis ein Signal (vereinfacht gedacht). So landet ein Impuls auf 0/0/3 sowohl über den "Entprellen-Zweig" als auch über den "Inverter-Zweig" gleichzeitig auf der Klemme (id 513), sofern die UND-Bedinungen erfüllt sind.

Und noch eins, dann hör ich auf ... ;-)
Ich gehe mal davon aus, dass dein Tag/Nacht-KO (581) vom Sonnenstand o.ä. gesetzt wird. Der folgende Flankendetektor gibt also immer abends (0 --> 1) auf A1 eine 1 aus. Dann wieder 24h nix und am nächsten Abend wieder eine 1. D.h. an dem folgenden UND steht nach dem ersten Abend immer eine 1. Vielleicht kann die 581 hier direkt dran?

Nur so ein paar wirre Gedanken zu deiner Logik von meiner Seite ...

**Escride** · 17.04.2019, 16:10

Ich habe enorme Probleme damit das nicht zyklisch gearbeitet wird. Als PC&SPS-Programmierer wird eben jede Bedingung in jedem Zyklus abgefragt und dann gesetzt.

Die Logik als solches stellt nur einen Kleinzeiler dar, mein Problem ist eben halt das komplette Umdenken und da hakt es. Habe mich nun nochmals damit beschäftigt für ne Stunde und bin eigentlich...nicht weiter.

Dadurch das ich zyklisch "denke" habe ich die Logiken auch immer wieder erweitert/geändert, wodurch mehr Chaos hineingekommen ist wie alles andere, siehe den Screenshot da oben

.

Ich versuchs erstmal noch weiter, muss ja irgendwie klappen.

Hier mal der Auszug wie ich es in openhab realisiert hatte und dort ja auch problemlos lief:

Code:

rule "Regel 7"
when
    Item Licht_Badezimmer received update or
    Item D_Badezimmer received update
then
    if((Licht_Badezimmer.state == ON) && Betriebsarten == 0)
    {
    sendCommand(D_Badezimmer, ON)
    Thread::sleep(450)
    sendCommand(E_Badezimmer, OFF)
    } else if ((Licht_Badezimmer.state == OFF) && Betriebsarten == 0) {
        sendCommand(D_Badezimmer, OFF)
        Thread::sleep(450)
        sendCommand(E_Badezimmer, ON)  
    }
end

Wenn Licht sich ändert oder Betriebsart Komfort, dann
wenn Licht an ist und Betriebsart Nacht dann
Betriebsart Komfort einschalten (D_)
Betriebsart Nacht abschalten (E_)
ansonsten
wenn Licht aus ist und Betriebsart Nacht dann
Betriebsart Komfort abschalten (D_)
Betriebsart Nacht einschalten(E_)
Ende

Die Umschaltung selbst lief über einen cronjob ab:

Code:

rule "Tagbetrieb"
    when
        Time cron "0 0/30 6-19 * * ?"
    then
        BetriebsartKomfort?.members.forEach[Switch|
            sendCommand(Switch, ON)
            Betriebsarten = 1
            Thread::sleep(300)
        ]
        BetriebsartNacht?.members.forEach[Switch|
            sendCommand(Switch, OFF)
            Betriebsarten = 0
            Thread::sleep(300)
        ]
    end

Anmerken hierzu muss ich, das in dem alten Code keine Wartezeit, sondern direkt umgeschaltet wurde. Eine Wartezeit einbringen ist ja auch kein Problem, wenn denn der Rest erstmal funktioniert.

**Escride** · 17.04.2019, 18:54

Danke erstmal für Eure Hinweise oben. Auf Dinge wie das SBC(remanent) wär ich im Leben so nicht gekommen.

Also ich bin nun mittlerweile soweit gekommen das es grundlegend funktioniert:

edomi_hzg1.png

Etwas was ich gerade gar nicht in den Griff bekomme:

1) Wenn 580 Tag/Nacht von 1 auf 0 wechselt während ODER 662 eine 1 führt (662+627 haben durchgehend 1), dann wird die Nachtabsenkung abgeschaltet. NUR wenn ich dort die Entprellung 954 einsetze wird erst abgesenkt und sofort wieder auf Komfort geschaltet. Das erzeugt natürlich ein Doppeltelegramm EIN/AUS was ich nicht möchte. Hat dafür jemand eine bessere Variante?

2) Am Ende nutze ich das vorgeschlagene SBC (remanent) was so auch ganz okay ist. Was ich aktuell mit den 2 Befehlen in den jeweiligen Ausgangsboxen mache ist:

Obere Box:
Befehl 1 - Komfort auf 1
Befehl 2 - Nacht auf 0

Untere Box:
Befehl 1 - Komfort auf 0
Befehl 2 - Nacht auf 1

Bekommt man das schöner hin? Einfach nur toggeln mag ich nicht, da der Zustand dann ungewiss ist. Es könnte auch irgendwann verdreht sein. Den Ausgang Toggle habe ich gesehen, hilft mir nur irgendwie nicht weiter.

3) Es ist zwischen dem A1-UND(941) und E2-UND(858) noch eine Zeit einzufügen die mit der linken Eingangsbox A1(KO 625) verknüpft wird. Nutze ich den Watchdog, so würde die 1 zwar exakt kommen, aber sobald eine 0 anliegt, bleibt der Ausgang des Watchdogs auf 1. Nutzt man dafür dann den Timer(stoppbar)? Hatte ich versucht, aber aus mir unerklärlichen Gründen habe ich E1 auf 0 gesetzt und A2 blieb anstehen wenn er einmal aktiviert wurde. Erst ein Telegramm=1 an E1 hat A2 abgestellt. Während der Wartezeit aber funktionierte es wie gewollt.

4) Durch meine ganze Try-Out Aktion habe ich nun IDs >1000. Kann ich das irgendwie sortieren bzw. optimieren sodass neu abgezählt wird?

Angehängte Dateien

edomi_hzg1.png (118,4 KB, 265x aufgerufen)

**MrIcemanLE** · 18.04.2019, 06:52

Vielleicht habe ich das Ziel nicht richtig verstanden, aber hier mal eine Idee von mir:
2019-04-18 07_49_09-EDOMI · Administration.png
Warum überschreibst du in deinen Ausgangsboxen das KO für die Nacht? Das ist doch ein unabhängiges "Steuer-KO", welches durch ZSU oder Helligkeit definiert ist.

Schau dir auch mal die unterschiedlichen Ausgangsboxen an. Da kann man sich einiges an UNDs oder ODERs sparen, da die Boxen z.B. nur auf Werte = 0 reagieren. Außerdem gibt es Befehle, die deinen eingehenden Wert an E1 in ein gewähltes KO schreiben.

Die KOs kannst du aber auch umbenennen, statt sie zu löschen. Dann werden die IDs auch nicht so hoch. Aber ansonsten kann man das nicht zurücksetzen oder so. Sortieren kannst die die KOs nach Namen oder ID. Außerdem kannst du Ordner bzw. Gruppen für die KOs erstellen.

Angehängte Dateien

2019-04-18 07_50_36-EDOMI · Administration.png (86,2 KB, 172x aufgerufen)

**Escride** · 18.04.2019, 15:54

Hey Iceman,

---
Das KO für die Nacht überschreibe ich in den Ausgangsboxen nicht. Dort wird jeweils direkt in die Gruppenadresse des entsprechenden Reglers geschrieben.
Also in dir GA für Betriebsart Komfort und Betriebsart Nacht. Diese beiden müssen immer entsprechend verdreht gesetzt werden. Daher auch zwei Befehle pro Box.
Das KO Tag/Nacht wird aktuell über eine ZSU gesteuert sowie per Button in der Visu umstellbar.
Das KO Heizperiode wird später (aktuell dauer 1) per DIN zusammen mit der Heizungsanlage Sommer/Winter umstellen.
Das KO FRG Umgehung wird die einzelnen Räume erlauben das diese trotz Nachtabsenkung per Licht Komfort haben dürfen (aktuell dürfen die kleinen Kids das nicht, die grossen schon, das Wohnzimmer auch, Gäste-WC aber z.B. nicht, etc. Soll einstellbar sein).

Daher auch zwei Eingangsboxen (Übersichtlichkeit):
Das obere für allgemeine Freigaben/Einstellungen der Logik,
das untere für die entsprechenden Lichtschalter (Wohnzimmer z.B. benötigt 4 Stück wegen der unterschiedlichen Leuchten).

---
Helligkeit als Tag/Nachtrhythmus habe ich mir noch nie angeschaut, das werde ich anhand des Gebäudes aber noch auslooten ob das sinnvoller ist, z.B. wegen Sonneinstrahlung erhitzt sich aktuell das gesamte Gebäude so sehr das die Räume trotz 2 Stunden vorher abgeschalteter Heizung 2-3°C Übertemperatur haben, lustigerweise im Winter aber nur marginal heizen (Vorlauf 37°C und Stellwerte zwischen 5-30% bei einfachen Heizkörpern).

---
Das mit den Ausgangsboxen, joa - jede Menge sind da. Daher habe ich ja die entsprechenden rausgesucht die bei jedem Telegramm außer 0 triggern und zur Speicherung damit nix doppelt passiert das SBC. Das geht auch gut.
Den Entpreller konnte ich mittlerweile auch ausklammern. Dafür musste ich (am oben geposteten Bild) an der UND-Box 858 noch ein invertiertes KO des Lihts mit anfügen was die Ausführung verhindert. Hatte das vorher nicht gesehen.

---
Das umbenennen von KOs ist kein Problem. Die KO-Nummern sind auch noch recht klein. Was ich meinte sind die ID-Nummern der Logikbausteine. Erstelle ich einen Baustein bekommt er eine eindeutige ID. Lösche ich diesen und erstelle einen neuen, z.B. wegen rumprobieren oder falsch ausgewählt, dann bekommt der neue nicht die gleiche bzw. erste freie sondern die nächsthöhere. Dadurch sind zwischen den Nummern Leerstellen enthalten, was (aus der Vorstellung heraus) einfach nur numerisch aufbläht. Hätte ja sein können das dieses "optimiert" werden kann.

Die Höhe der KO-IDs ergibt sich ja durch das KNX-System. Aktuell sind 582 GAs vorhanden, knapp 900 GAs sind aktuell noch leer, werden aber noch aufgefüllt. Allein für den Garten habe ich darin 190 geplant (Beregnungen, Beleuchtungen, Steckdosen, Brunnen, Teich, ...) Also die werden so oder so noch nach oben eilen, wurden nur jetzt noch nicht übernommen da sie leer sind und ETS5 sie deshalb nicht exportiert hat (oder edomi importiert, habe nicht nachgesehen). Viele GAs sind für edomi später auch uninteressant, aber da ich ausnahmslos von allen im KNX-System vorhandenen Geräten den Kommunikationsobjekten immer eine GA zuweise (für spätere Änderungen muss ich das entsprechende Gerät dann nicht immer partiell programmieren) sind halt soviele vorhanden. edomi nutzt aktuell glaub grad mal 300 davon, bin ja erst seit Sonntag dabei.

---
Muss eben noch an einigen Punkten feilen, im groben und ganzen aber läuft es nun, dafür auch gleich schneller und flüssiger als im vorherigen openhab (dem ich gerade in keinster Weise nachtrauere).

Ankündigung

Logik scheint nicht so logisch wie ich es mir vorstelle, steh nun auf dem Schlauch

Logik scheint nicht so logisch wie ich es mir vorstelle, steh nun auf dem Schlauch

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar