Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    henfri
    @henfri
    woran kann es denn liegen, wenn beim Neustart von smarthome einige Lichter an gehen?
    Alle Einstellungen bezüglich des Verhaltens beim Start, die mir geläufig sind lesen doch alle nur und schreiben nicht, oder?
    Morg42
    @Morg42
    Dafür müsste man in die item-Config schauen, sonst ist das schwierig zu beantworten.
    henfri
    @henfri
    Naja, eins der Items hat z.B. nur knx_send und knx_cache
                W:
                    knx_send:  1/1/0
                    knx_cache: 1/1/3
                    alexa_device: Till_Stripe_Oben
                    alexa_name: 'Till Stripe oben'
                    alexa_description: 'Till Lichterschlauch oben'
                    alexa_icon: 'LIGHT'
                    alexa_actions: 'TurnOn TurnOff'
    
                    Dimmwert:
                        knx_send:  1/1/2
                        knx_cache: 1/1/4
                        alexa_actions: 'AdjustBrightness SetBrightness'
                        alexa_retrievable: True
                        alexa_item_range: '0-100' 
                        alexa_device: Till_Stripe_Oben
                        alexa_name: 'Till Stripe oben'
                        alexa_icon: 'LIGHT'
    Aber es hat auch eine Szene.
    bzw. es ist Teil einer Szene
            Szene:
              type: scene
              knx_cache: 10/1/2
              knx_send: 10/1/2
              knx_dpt: 18.001
              enforce_updates: 'true'
    Morg42
    @Morg42

    Nur die knx-Config vom Item sieht ok aus (schau im Log, ob der Cache Fehler beim Start wirft).
    Wie verhält sich denn alexa beim Start? Kommentier doch mal das Alexa-Plugin in der plugin.yaml aus und starte. Passiert das gleiche?
    Mit Szenen kenne ich mich nicht aus. Könnte gegebenenfalls beim Start die Szene reinpfuschen? -> Szene auskommentieren und nochmal probieren.

    So kannst du systematisch die Quelle eingrenzen.

    Onkel Andy
    @onkelandy
    Passiert das immer bei den gleichen items oder zufällig? Knx cache liest ja vom knxd cache - eventuell ist da ein falscher/alter Wert drin? Könntest mal auf knx_init stellen. Ist zwar nicht so prickelnd wegen buslast und eventuell verschluckter Telegramme, aber zum Debuggen n versuch wert
    bmxp
    @bmxp
    Zumindest würde ich explizit immer den knx_dpt und den type angeben.
    msinn
    @msinn
    Ich habe die Szene im Verdacht. Szenen haben ja nur einen sinnvollen Wert wenn sie ausgelöst werden und keinen dauerhaften Zustand. Du liest aber beim Neustart den letzten gesendeten Szenenwert (der vieleicht von vor 2 Tagen stammt) ein und gibst ihn über enforce_updates dann auch wieder aus (zumindest an nicht-Knx Komponenten der Szene).
    henfri
    @henfri
    Hallo
    und gibst ihn über enforce_updates dann auch wieder aus (zumindest an nicht-Knx Komponenten der Szene).
    Es reagieren aber ja KNX-Komponenten
    Aber auch die würden ja ein knx_send auslösen, wenn sie Teil der Szene sind (ich habe alle Szenen in sh.py, auch von KNX Komponenten, da einige doch recht eingeschränkt sind, was Szenen angeht)
    Ich denke, ich sollte mal das enforce_updates rausnehmen
    Es passiert immer bei den gleichen Items, soweit ich das gesehen habe
    @Bernd: dpt und type sind über einen struct vorgegeben, sorry, das konnte man natürlich nicht sehen
    msinn
    @msinn

    Es reagieren aber ja KNX-Komponenten

    Deshalb hatte ich zumindest geschrieben, da ich nicht sicher bin ob Szenen auf diesem (um-)Weg bei der Initialisierung auch auf KNX mit ausgegeben werden und nicht die Zeit habe das für Dich zu testen.

    Insgesamt macht bei Szenen ein knx_cache oder ein knx_init keinen Sinn, da niemand auf einen lesenden Bus Request einer Szene antwortet. knx_cache hängt im Ergebnis also davon ab, ob seit dem Start von knxd mal eine Szene gesendet wurde.

    Falls Du nur KNX Komponenten in der Szene hast, einfach das knx_cache ersatzlos weglassen. Falls Du auch andere Komponenten in der Szene hast, ein knx_listen verwenden. Das enforce_updates wirst Du brauchen, weil Du sonst von SmartHomeNG aus nicht zwei mal hintereinander die selbe Szene ansteuern kannst.

    henfri
    @henfri
    Ok, das macht Sinn. Ich habe jetzt auch nochmal nachgeschaut und im Admin-Interface ist sichtbar, dass die Antwort vom Taster kommt, der die Szene setzt.
    Ich nehme das knx_cache/init raus
    Michael
    @michischatz
    Guten Abend, ich habe nochmal ein Verständnis-Problem bei der Pluginentwicklung: Mit welcher Funktion kann ich dem Item einen Wert zurückgegeben/zuweisen, damit das bei Item als Wert im Admininterface angezeigt wird? parse_item versteh ich nicht ganz wie das mit update_item korrespondieren soll, vor allem weil zweitere Funktion wohl nur gedacht ist, um Änderungen an Itemwert an das Device zu schicken?
    bmxp
    @bmxp

    Die parse_item wird beim Laden des Plugins für jedes Item aufgerufen. Dort untersucht das Plugin of das Item bestimmte Attribute aufweist. Ist das der Fall, dann wird das Item z.B. in ein Plugin-eigenes Dictionary aufgenommen und die Funktion gibt als Rückgabewert eine Referenz auf eine update_item Funktion zurück.
    Wenn sich nun im Laufe der Ausführung von SmartHomeNG ein Item ändert und für dieses Item ein Eintrag für das Plugin und dessen update_item Methode existiert, dann wird diese Methode mit den Parametern item, caller, source und dest aufgerufen.
    In der Updaten_item Methode wird dann geprüft wo der Ursprung der Item Änderung liegt. Ist das ausserhalb des Plugins (z.B eine Logik oder ein anderes Plugin) dann wird darauf reagiert,

    Wenn Du in Deinem Plugin ein Item ändern möchtest, dann rufst Du einfach das Item wie in einer Logik auf mit einem Parameter der den neuen Wert beeinhaltet.

    Michael
    @michischatz
    ach danke! Ich habs jetzt auch die Beschreibung dazu gefunden, ist in der Funktion poll_device im sample_plugin: Müsste so gehen: item(device_value, self.get_shortname()) Probier ich morgen aus
    Morg42
    @Morg42
    Es reicht auch item(wert)...
    Michael
    @michischatz
    gracias
    msinn
    @msinn

    Es reicht auch item(wert)

    Dann wird im Admin Interface allerdings nicht angezeigt, wer/was den Wert verändert hat. Deshalb besser:
    item(wert, self.get_shortname())

    Onkel Andy
    @onkelandy

    Hat jemand eine Idee, wie ich das Logging dazu bringe, den Monat auf Englisch zu loggen statt Deutsch? Das System möchte ich generell schon Deutsch lassen, nur das Logging nicht. So sieht meine Config aus:

    format: '%(asctime)s;%(message)s;'
    datefmt: '%b %d %H:%M:%S'

    Das Ergebnis sollte Mar 02 18:09:49 WARNING statt Mär 02 18:09:49 WARNING sein. Wäre über Hilfe sehr froh.

    Morg42
    @Morg42

    Wenn ich das richtig verstehe, nutzt logging strftime - und damit geht die Formatierung nur entsprechend der aktuellen locale.

    Du kannst ja mal versuchen, vor dem Aufruf von shng die locale zu ändern (auf en_US oder C oder so). Die generellen Spracheinstellungen von shng kommen ja nicht aus der locale, sondern aus der EInstellung für shng, oder?

    redist2
    @redist2
    Guten Abend zusammen. Gibt es eine Möglichkeit die Datenbankeinträge eines Items in ein anderes (neues) zu kopieren?
    Michael
    @michischatz
    Guten Abend, willst du das einmalig machen? Dann würd ich klassisches SQL Update machen und die Item-ID in der der DB updaten
    oder Insert mit Select Statement, würde wahrscheinlich auch gehen
    redist2
    @redist2
    @michischatz Danke für die Hilfe hat geklappt :)
    Onkel Andy
    @onkelandy
    Möcht nochmals auf mein Loggingproblem oben zurück kommen. Hab in smarthome.py mal die Zeile zum Setzen des Locales geändert. Setze ich das nicht auf UTF-8, gibt's zB Probleme bei Sonderzeichen in Kalendern in Zusammenhang mit ical, etc. Setze ich es auf en_US.UTF-8 wird's lustig. Das locale ist nicht installiert. Installiere ich es via sudo locale-gen en_US.UTF-8, wird aber nur en_GB.UTF-8 installiert. WTF? Vielleicht wäre das in Zeile 193 von smarthome.py abzuändern oder zu erweitern?
    Jedenfalls mit en_GB bekomme ich soweit das Ergebnis im Log wie ich es will, Fehler gibt es auch keine. Admintool ist deutsch. Frage: Wo wird das setlocale genau genutzt und könnte man das in der smarthome.yaml konfigurierbar machen...?
    Morg42
    @Morg42
    Die Locale wird eigentlich beim Start der Shell gesetzt, das ist ja eine Benutzereinstellung. Also z.B. in der .bashrc oder .bash_profile...
    Programme sollten die - eigentlich - für sich nicht ändern, sondern die Einstellung nehmen, die da ist. Es sei denn, es gibt eine Option, dass der Benutzer eine andere Einstellung auswählt. Ich habe aber noch kein Programm gesehen, wo du die Locale auswählst, höchstens die Sprache der Oberfläche...
    bmxp
    @bmxp
    Das mit der locale ist für mich auch ein ungelöstes Thema in Bezug auf die Windows Variante. Allerdings dort eher mit Bezug auf den Systemzeichensatz der Console der dort als default nicht UTF-8 ist sondern CP1252
    Onkel Andy
    @onkelandy

    Also die locale wird auch in smarthome.py gesetzt.. ab Zeile 187.

        try:
            if locale.getdefaultlocale() == (None, None):
                locale.setlocale(locale.LC_ALL, 'C')
            else:
                locale.setlocale(locale.LC_ALL, '')
        except:
            locale.setlocale(locale.LC_ALL, 'en_US.UTF-8')

    @Morg42 Dein Vorschlag wäre aber, zB beim shng Service Fail ein PreStart einzufügen, wo die locale via export LC_ALL=en_US.UTF-8 systemweit geändert wird?

    Michael
    @michischatz
    Guten Abend, ich hätte mal Frage zur Pluginentwicklung: Wenn ich ein Plugin für mehrere Geräte verwenden möchte, muss ich dann Instanzen verwenden oder kann ich einfach auch verschiedene Konfigurationen verwenden? Die erhalten ja auch einen Namen bzw. kann ein eigener Name vergeben werden..
    Onkel Andy
    @onkelandy
    Instanzen, damit du die item Attribute der richtigen config zuordnen kannst
    Michael
    @michischatz
    Okay, du meinst quasi dass ich im Item sagen kann als Beispiel: <pluginname>@<Instanz> richtig? Mein Gedanke wäre gewesen <pluginname>_<pluginconfigname> zu verwenden. Das wird warhrscheinlich nicht funktionieren oder?
    Morg42
    @Morg42

    Also die locale wird auch in smarthome.py gesetzt.. ab Zeile 187.

    Für die Logik fehlt mir wohl noch ein Detail. Wenn keine Locale vom System kommt, setzt er "C" als LC_ALL (ok); wenn es eine gibt, löscht er sie (??)

    Und wenn dabei ein Fehler auftaucht (beim Lesen oder Setzen?) versucht er, en_US zu setzen.

    Das erschließt sich mir noch nicht. Ich vermute, dass damit das Verhalten verschiedener Betriebssysteme abgefangen werden soll?

    @Morg42 Dein Vorschlag wäre aber, zB beim shng Service Fail ein PreStart einzufügen, wo die locale via export LC_ALL=en_US.UTF-8 systemweit geändert wird?

    Ich weiß nicht, ob deine Anwendung mit anderssprachigem Log so typisch ist. Wenn du für deinen Anwendungsfall die Sprache im Log ändern willst, würde ich z.B. für den User smarthome die Locale anpassen. Ich weiß jetzt aber nicht, inwieweit shng die ggf. selbst wieder überschreibt.

    Nach der Logik oben sollte ja LC_ALL entweder C, '' oder en_US.UTF-8 sein. Da dürfte es überhaupt keine deutsche Datumsausgabe geben. Ich muss da ggf. nochmal in den Code schauen, wenn sonst niemand das erklären kann ;)

    Michael
    @michischatz
    Guten Morgen, leider kann ich zum Locale Thema nicht viel beitragen :( Hätte allerdings nochmal Frage zu Instanzen: Ich finde kein Item mit Items.find_items(name nach item_attributes Definition in plugins/plugin.yaml) sobald ich mit Instanzen arbeite. Muss ich da was spezielles beachten? die Items habe ich in der Item.yaml angelegt mit <name nach item_attributes Definition in plugins/plugin.yaml>@<Instanzname>: Wert. Sollte doch theoretisch funktionieren?
    Onkel Andy
    @onkelandy
    ad Instanz: Also im plugin.yaml musst du ja instance: xy angeben, dann sucht das Plugin Items mit dem Attribut bla@xy
    Onkel Andy
    @onkelandy
    ad locale: Wenn ich das für den smarthome User einrichte, wirkt sich das ja systemweit auch auf die shell aus, oder? Fände ich nicht so gut. Anforderung nach engl. Logging hab ich, weil ich für logcheck (sendet ne Mail bei Error Messaeges, etc.) noch ein Tool syslogsummary im Einsatz habe, das gleiche Logzeilen kumuliert. Die Zeilen im smarthome.py wird es eventuell für Mac OS brauchen, da hab ich jedenfalls ein automatisches Setzen auf en_US. Weiters vermute ich, dass das Setzen auf '' dafür sorgt, dass das environment locale genutzt wird. Insofern wäre schön, für besagte Zeilen im smarthome.yaml die locale für shng angeben zu können. Was meinst du @msinn ?
    bmxp
    @bmxp
    Wozu zum Teufel brauchst Du denn ein englisches statt deutsches Logging für den Monat? Reicht dann nicht der Monat als Zahl aus?
    Morg42
    @Morg42
    Hm. Das Konzept locale ist aber eigentlich gerade die "userweite" Einstellung. Machst du denn viel als User "smarthome" in der Shell?
    Ich würde eher schauen, ob man nicht logcheck und syslogsummary auf die entsprechenden (deutschen) Texte oder Zahlen (@bmxp) anpassen kann...?
    bmxp
    @bmxp
    Ich denke, das evtl. der Formatter angepasst werden könnte. In diesem Thread https://stackoverflow.com/questions/6290739/python-logging-use-milliseconds-in-time-format sind einige Ideen dazu.