Ankündigung

Einklappen
Keine Ankündigung bisher.

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

Einklappen
X
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

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

    Hi,

    ich ziehe gerade von OpenHab2.4 auf Edomi um und habe soweit das was ich in Openhab alles programmiert hatte nun auch umgesetzt, teilweise auch mehr.

    Allerdings stoße ich nun an einer Logik an die Grenzen. Ich habe sie erstellt, getestet mit einem Raum, schien zu funktionieren, alle anderen Räume erstellt, getestet und geht nicht so wie ich es wollte.

    Mein Ziel:
    - Ein KO "Tag/Nacht 1=Nacht" schaltet per Zeitschaltuhr die Räume gleichzeitig in die Nachtabsenkung.
    - Ist in einem Raum aber noch Licht WÄHREND der Nachtabsenkung, so soll dort die Betriebsart auf Komfort bleiben.
    - Wird in einem Raum während der Nachtabsenkung das Licht eingeschaltet, so soll wieder Komfort nach Zeit X aktiviert werden.
    - Schaltet die Zeitschaltuhr das KO wieder aus, so wird Komfort für Tagbetrieb wieder aktiviert, Licht ist nun uninteressant.

    Bevor jemand meckert warum ich das will: 3 Erwachsene in einem Haus mit unterschiedlichen Arbeitszeiten und Schlafrhythmen. Also muss manchmal um 3 Uhr Nachts im Bad die Heizung noch an sein, oder Abends vor dem Fernseher der Raum länger warm bleiben wie die anderen. Dafür wird dann primär das eingeschaltete Licht genommen, später auch Fernseher (Wohnzimmer), aber nicht erst zum Panel rennen um dort einen Button zu drücken und an den Lichtschaltern mag ich das auch nicht, da die kleinen dauernd dran rumspielen werden.


    Meine bisherige Logik funktionierte erst soweit das sie tagsüber die KO ignoriert hat und bei der Umschaltung auch im Komfort blieb als das Licht an war.
    Dann aber habe ich scheinbar beim Umschieben/optimieren irgendwas geändert beim Erstellen der Räume und komm einfach nicht mehr drauf wie es vorher war.

    Jetzt ist es so, das tagsüber Licht ein/aus ignoriert wird, aber nur ein Mal. Beim zweiten Schalten Ein+Aus ist die Nachtabsenkung in dem Raum aktiv.
    Schalte ich nun um in die Nachtabsenkung mit aktiviertem Licht, so wird die auch umgeschaltet.

    Also funktioniert sie nur ein Mal nachdem Edomi neu gestartet hat, und zwischenzeitlich dann auch nicht zuverlässig.

    edomi_hzg.png
    Soweit ist die Logik aktuell, nur nicht funktionell.


    Vielleicht kann mir jemand bei der Logik behilflich sein, oder gar eine bessere Variante empfehlen.
    Angehängte Dateien

    #2
    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



    Die Selbsthilfegruppe "UTF-8-Probleme" trifft sich diesmal abweichend im groüen Saal.

    Kommentar


      #3
      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 ...
      Gruß
      Stefan

      Kommentar


        #4
        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.

        Kommentar


          #5
          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

          Kommentar


            #6
            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
            Gruß
            Stefan

            Kommentar


              #7
              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).

              Kommentar

              Lädt...
              X