Ankündigung

Einklappen
Keine Ankündigung bisher.

Logiken: Beispiele als Bausteine ins Release oder kommentiert ins Wiki?

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

    Logiken: Beispiele als Bausteine ins Release oder kommentiert ins Wiki?

    Inwieweit ist es eigentlich gedacht, Logiken mit in den Release zu nehmen bzw. direkt schon im Code zu verbauen, damit man da evtl. leichter drauf zugreifen kann?
    Ich denke hier insbesondere an 2, 3 Sachen, die wirklich jeder brauchen könnte.... die Codeschnipsel stammen primär aus dem Forum hier.

    Eine wirklich gute Funktion, die man aber noch ordentlich überarbeiten müsste, um zB Doppel- und Dreifachklicks mit Tastern abzufangen, also ein Multiclick Item:
    Code:
    #!/usr/bin/env python
    # -*- coding: utf-8 -*-
    logger.info(trigger)
    
    invalue = trigger['value']
    item = sh.return_item(trigger['source'])
    scitem = sh.return_item(trigger['source']+'.singleclick')
    mcitem = sh.return_item(trigger['source']+'.multiclick')  
    scheduletask = 'singleclick-'+str(item)
    logger.debug("Multiclick getriggert durch: {0}".format(item))
    #if item() == 1:
    if 'click_count' in item.conf: 
        count = int(item.conf['click_count'])
        logger.debug("Previous Age: {0}".format(item.prev_update_age()))
        if hasattr(logic, 'save_state_' + item.id()):
           if item.prev_update_age() < 0.8:
              val = int(getattr(logic, 'save_state_' + item.id())) + 1
              setattr(logic, 'save_state_' + item.id(), val)
              logger.debug("Klickcount: "+str(val))
           else:
              setattr(logic, 'save_state_' + item.id(), 1)  
    
        else:
             setattr(logic, 'save_state_' + item.id(), 1) 
    
        if int(getattr(logic, 'save_state_' + item.id())) > count-1:       
           sh.scheduler.change(scheduletask, active=False)
           setattr(logic, 'save_state_' + item.id(), 0)
           logger.debug("Fuehre Multiclickitem aus")
           mcitem(1)
        else:  
           logger.debug("Fuehre Singleclickitem aus")  
           next_time = sh.now() + dateutil.relativedelta.relativedelta(seconds=1)
           sh.scheduler.add(scheduletask, scitem, prio=3, cron=None, cycle=None, value=invalue, offset=None, next=next_time)
           #setattr(logic, 'save_state_' + item.id(), 0)
    Bei dieser Logik braucht es aber noch ein, zwei Anpassungen im item.py selbst. Darum denke ich, dass gerade hier eine direkte Implementierung in den Code ganz clever wäre.


    Network Plugin Logik, damit ein Item direkt seinen Wert übers Netzwerk zB an eine zweite SmarthomeNG Instanz schicken kann:

    Code:
    if trigger['by'] == 'Item':
        lItemName = trigger['source']
        lItem = sh.return_item(lItemName)
        sh.nw.udp('10.0.0.152', 9999, 'item|{0}|{1}'.format(lItemName, lItem()))
        logger.info("udpSend: {0}, {1}".format(lItemName, lItem()))
    else:
        logger.debug("Keine Triggerung udpSend von Item")
    Zwangswerte bzw. Prioritäten (knx DPT 2) können derzeit auch nicht über die Visu gesteuert werden, hier muss man sich eines Hilfsobjekts bedienen und das Ganze dann auch mittels Logik raus feuern, damit das klappt.
    Code:
    #!/usr/bin/env python
    #
    logger.info(trigger)
    
    source_item = sh.return_item(trigger['source'])
    prio = trigger['value']
    logger.debug("Trigger Item for Priority Logic: {0}, Value: {1}".format(source_item,prio))
    
    has_zwang = False
    has_sperrenaus = False
    has_sperrenwert = False
    
    search_id = source_item.id()+".zwangsstellung"
    for child in source_item.return_children():
         if child.id() == search_id:
                has_zwang = True
                
    if has_zwang:
        if prio == 0:
            source_item.zwangsstellung([0,0]) 
        elif prio == 1:
            source_item.zwangsstellung([0,1])
        elif prio == 2:
            source_item.zwangsstellung([1,0])
        elif prio == 3:
            source_item.zwangsstellung([1,1])
    else:
        logger.debug("Kein Zwangsstellungsitem.")
    Bei manchen Plugins wäre auch die Frage, ob nicht gleich eine Beispiellogik mit rein sollte, denn ohne Logik funzt es ja nicht (Mail, Pushbullet, etc.). Klar, die nötigen Infos stehen dann in den Readmes, aber evlt. könnte man hier die Herangehensweise doch auch etwas erleichtern...?

    #2
    Zitat von Onkelandy Beitrag anzeigen
    Bei manchen Plugins wäre auch die Frage, ob nicht gleich eine Beispiellogik mit rein sollte, denn ohne Logik funzt es ja nicht (Mail, Pushbullet, etc.). Klar, die nötigen Infos stehen dann in den Readmes, aber evlt. könnte man hier die Herangehensweise doch auch etwas erleichtern...?
    Wollen haben! ☺
    Sowas wie example.py in jedem Plugin Ordner was vom system ignoriert wird, aber für den Nutzer hilfreich ist.

    Kommentar


      #3
      Zitat von Onkelandy Beitrag anzeigen
      Inwieweit ist es eigentlich gedacht, Logiken mit in den Release zu nehmen
      Dafür!
      Quasi wie das Logikbaustein Archiv vom Edomi oder HS.

      Dafür sollten die Logiken aber auch so aufgebaut sein.
      In den ersten Zeilen wird die Schnittstelle also die Input und Output items zugeordnet und der weitere Code bleibt vom Nutzer komplett unberührt.

      Gruß,
      Hendrik

      Kommentar


        #4
        oder halt die logiken ins wiki, ich hatte da mal angefangen: https://github.com/smarthomeNG/smart...ogik-Beispiele


        oft muss man die halt auf seine items anpassen, daher ist im code repository mE der falsche ort. so setzt man sich mehr damit auseinander.

        Plus: im Wiki kann man noch gut dinge dazu erklären...
        Zuletzt geändert von psilo; 06.08.2016, 11:33.

        Kommentar


          #5
          Ich fände ein Bausteinsystem schon sehr nett. Am besten sogar so, dass man die nötigen Attribute im logics.conf definiert wie bei Plugins. Die werden dann brav bei der Logik zu Beginn abgefragt und gut ist. Doku dann wie bei den Plugins via Readme. Wie gesagt, gerade bei Plugins, wo es ohnehin fix eine Logik braucht, fände ich das gut.. und für die Integration der Multiclick-Funktionalität plädiere ich sowieso ganz massiv. Das geht ja glaub beim HS auch, oder?

          Ach ja, das wettercom Plugin braucht auch zwingend eine Logik, in die man dann noch selbst einen Wert rein schreiben muss. Wär auch hier natürlich übersichtlicher, das Attribut gleich in der conf anzugeben und die Logik direkt mitzuliefern, da das Plugin ohne ja nicht läuft.. Und gerade, wenn sich mal was in Bezug auf die Abfrage von wetter.com tut (wie es derzeit irgendwie zu sein scheint. kann nicht mehr auf mein Projekt zugreifen!?), könnte man die Updates leichter integrieren..
          Zuletzt geändert von Onkelandy; 07.08.2016, 00:03.

          Kommentar


            #6
            das Thema Logik ist eine getrennte Baustelle. irgendwann wollten wir ja auch mal einen grafischen Editor bauen. mE sollten Plugins im Wesentlichen ohne Logik auskommen, die älteren sind halt leider noch so und ein Umbau kostet eben auch Zeit.

            Wenn wir das Logikverzeichnis mit Beispielen zuknallen blickt mE am Ende niemand mehr durch. zu den genannten Plugins gibt es von Einsteigern genug Fragen wegen der Logik, ohne scheint besser zu funktionieren. Drum bin ich weiter dafür das Wiki mit Beispiellogiken anzureichern. Für zukünftige Releases können wir uns alle gemeinsam aber gerne Gedanken machen. Ich sehe aber wichtigere Baustellen.

            PS: Wetter.com geht bei mir
            PS2: ich glaube die wenigsten hier haben einen sündhaft teuren HS im Keller stehen, ich zumindest nicht, daher k.A.

            Kommentar


              #7
              Ich als einfacher Anwender wäre auch dafür, Beispiellogiken ins Wiki einzupflegen.
              Bezüglich Logikeditor wurde doch mal ein Ansatz mit "Google Blockly" angesprochen... Wäre (zumindest aus meiner Sicht) ein sehr interessanter Ansatz. Dieser würde Einsteiger ansprechen/unterstützen und parallel könnten die Python-Profis weiterhin "normal" programmieren.

              Kommentar


                #8
                Hallo,

                Der Nachteil eines (alleinigen) Wiki für die Logiken ist, dass alleine durch das Copy-Paste Fehler entstehen (Einrückungen, Tabs). Darüber hinaus könnte man Logiken im Git auch in die Tests einbinden.

                Die Logiken müssen so gebaut werden, dass Items nur oben zugewiesen werden und weiter unten in der Logik generische Variablen verwendet werden.

                z.B.:

                Code:
                Klingel=eg.Haustuer.Klingel()
                Licht=og.Schlafzimmer.Licht()
                
                #--------Do not modify below this line--------
                
                if Klingel:
                   Licht(1)
                Auf diese Weise würden wir es denjenigen, die keine Programmierkenntnisse haben leichter machen.

                Gruß,
                Hendrik

                Kommentar


                  #9
                  Ich habe im Wiki die von psilo begonnene Auflistung mal erweitert und alle Logik-Beispiele aufgeführt, welche ich im Wiki gefunden habe.
                  Es gab bereits eine ähnliche Seite mit einer Auflistung von Beispiellogiken im Wiki von 2015. Diese habe ich gelöscht.

                  Ich wusste nicht so recht, wo die Grenze zwischen den simplen und komplexen Beispielen liegen soll. Ihr könnt die Zuordnung also gerne überprüfen und ändern.

                  Kommentar


                    #10
                    Zitat von Boomer55 Beitrag anzeigen
                    ....
                    Bezüglich Logikeditor wurde doch mal ein Ansatz mit "Google Blockly" angesprochen... Wäre (zumindest aus meiner Sicht) ein sehr interessanter Ansatz. Dieser würde Einsteiger ansprechen/unterstützen und parallel könnten die Python-Profis weiterhin "normal" programmieren.
                    Mir fehlte damals die Unterstützung, die Blocky Seite in die SV einzubauen. Funktioniert hat der Ansatz im Prinzip.
                    Wahrscheinlich wäre eine Integration in das neue Backend sowieso sinnvoller. Dieses habe ich mir allerdings noch nicht angesehen.
                    Meinungen dazu?

                    Gruß, Dirk

                    Kommentar


                      #11
                      das wäre einer meiner pläne für die 1.3 - alternativ vielleicht gemeinsam richtung neuer visu.

                      den code für logiken zeige ich ja schon an, im endeffekt sollte sich das ins blockly füttern lassen. man müsste vorher aber mal nen groben proof of concept bauen, der muss ja nicht zwingend rund sein

                      Kommentar


                        #12
                        Blockly im Backend finde ich eine sehr gute Idee. Da wäre es sicher besser aufgehoben als in der SV - SH.py kann ja auch ohne SV verwendet werden.

                        Kommentar


                          #13
                          Zitat von psilo Beitrag anzeigen
                          ...
                          den code für logiken zeige ich ja schon an, im endeffekt sollte sich das ins blockly füttern lassen. man müsste vorher aber mal nen groben proof of concept bauen, der muss ja nicht zwingend rund sein
                          "handgeschriebene" Logiken lassen sich wohl nicht direkt 1:1 in Blockly-Logiken umwandeln. Diese werden in einem XML-Code gespeichert, aus dem sie in Python-Code umgewandelt werden. In meinem Ansatz liegt beides als Item-Value im Speicher und kann mit Hilfe von cache=true persistiert werden. Dieses Konzept müsste passend zum Ansatz des Backend-Plugins geändert werden.

                          Welches Framework verwendet das Plugin?
                          ... habe ich mir eben selbst beantwortet. Schaue ich mit nachher mal an. (Schön!: alles Python)
                          Zuletzt geändert von walldi; 09.08.2016, 13:56.

                          Kommentar


                            #14
                            eben das war auch meine sorge. drum hab ich bisher auch nicht gross los-"geprototyped" und das auf die kalte jahreszeit verschoben, unter dem blick, dass wir es gegen das thema visu abwägen. wenn sich natürlich jemand berufen fühlt...

                            als erster schritt wäre schon genial, den code im backendplugin zu editieren und die logik "reloaden" zu können.

                            Kommentar


                              #15
                              Zitat von psilo Beitrag anzeigen
                              als erster schritt wäre schon genial, den code im backendplugin zu editieren und die logik "reloaden" zu können.
                              Zum editieren wäre es natürlich super, wenn wir einen Code Editor wie z.B. CodeMirror ins Backend einbinden würden.
                              Ich könnte dies versuchen.
                              Allerdings ist das reloaden natürlich Voraussetzung. Wenn ich es richtig verstanden habe, ist dies aber bereits implementiert.

                              Kommentar

                              Lädt...
                              X