Beiträge von horschte

Zitat von buers

Dadurch werden sich die zugewiesenen Werte ja kaum ändern

der name der sendung wird in dem fall mittels http binding in openhab nur alle 60sek aktualisiert, daher die notwendige wartezeit.
patrik hat lediglich einen logikfehler in seiner rule. die werte werden da am anfang bestimmt, dürfen jedoch erst nach dem timer bestimmt werden.
zum thema sleep findest du hier ein paar infos:
https://community.openhab.org/t/why-have-my-…-bad-idea/47695

ok ich hab mir mal den schalter angeschaut. er hat keine "mechanische" on/off stellung. weiterhin:

Zitat von zigbee2mqtt

Triggered action (e.g. a button click). Value can be found in the published state on the action property. It's not possible to read (/get) or write (/set) this value. The possible values are: on, off, brightness_move_down, brightness_move_up, brightness_stop.#

ein command channel ist also nicht vorhanden. damit ist das synchronisieren des tasters mittels command also auch nicht möglich (wenn man bspw nicht mit dem xiaomi taster oder dem shelly das licht steuert)
das ganze bringt ein problem mit sich....schaltet man am ikea taster ein, dann geht das licht und der andere schalter (shelly) ein. schaltet man jetzt am xiaomi aus, dann bleibt der ikea schalter trotzdem auf on. die oben gepostete rule würde also nicht triggern wenn man jetzt wieder beim ikea schaltet...weil sich dessen status (der auf on ist) nicht ändert.
in der o.g. rule würde ich also den trigger von "changed" auf "received update" umstellen.
falls der schalter auch ohne aktion seinen status sendet (kommt ggf beim neustart vor -> changed from NULL to ON/OFF), dann würde das licht ungewollt schalten. um das zu umgehen, könnte der rule trrigger von changed/received update auf:

Channel "mihome:86sw1:158dxxx710316:ch1" triggered SHORT_PRESSED or
    Item Hannes_switch2Click changed from OFF to ON or
    Item Hannes_switch2Click changed from ON to OFF

...abgeändert werden. so triggert die rule wirklich nur, wenn am taster was gedrückt wird.
ein anderer weg (darauf will @bennySB sicher hinaus) wäre mittels "received command" zu triggern und dann auf "SHORT_PRESSED" (vom xiaomi) sowie "ON/OFF" (vom ikea) mittels 3x case (sind ja 3 "zustände") zu reagieren.

Zitat von bennySB

Ob der Schalter dann eine interne Speicherung der Position vornimmt weiß ich nicht.

er hat ein item angelegt. also wird der status ja (zumindest bei openhab) gespeichert.

Zitat von xSaSx

ich denke weil es wirklich 2 "knöpfe" an dem tradfri gibt mit on und off oder ?

das war nicht in den ersten beiträgen erkennbar.

Zitat von xSaSx

Configuration model 'hannes_lichtschalter.rules' has errors, therefore ignoring it: [5,5]: no viable alternative at input 'Hannes_switch2Click'

ich denke weil es wirklich 2 "knöpfe" an dem tradfri gibt mit on und off oder ?

ne das hat damit nichts zu tun. beim zusammenstellen deiner rule habe ich beim trigger nur "Item" vergessen. es muss heissen "Item Hannes_switch2Click changed"

Zitat von bennySB

Warum sinnfrei? Es muss sich ja nicht um einen Taster handeln, siehe:

ok das es auch "echte" schalter von ikea gibt wusste ich nicht. hat der taster denn eine "mechanische" on/off stellung? erst dann macht es doch sinn den status auch zu auszuwerten. wenn das licht an ist, dann drücke ich ja nicht auf on.

Zitat von xSaSx

aber deine rule sieht logisch und einfach aus

genau so solls nach möglichkeit ja auch sein. wenn du mit nem einfach-klick das licht schalten willst, dann brauchste keine receivedEvent variablen um andere klicks auszuwerten. die rule wird einfach nur lang und unübersichtlich.
solltest du andere klicks auswerten lassen um andere geräte zu schalten, dann kommt das halt in eine eigene rule. an codezeilen spart man auch nicht wirklich was wenn man das alles mit einem mal auswerten will.

Zitat von xSaSx

in der neuen rule engine was man so zusammenklicken kann gibt es kein else oder ?

grafische rule engine benutzen??????????????

on/off bei taster...total sinnfrei meines erachtens.....naja, dann ist es halt so.
so wie du es weiter oben geschrieben hast, verliert der taster natürlich die on/off funktionalität. wobei das meines erachtens auch völlig egal wäre. das brauchst du für deinen einsatzzweck nicht.
ich würde die anderen drei strings des xiaomi (DOUBLE_PRESSED etc) zusätzlich aus dieser rule entfernen. wenn du diese funktionen nutzen willst, dann nimm ne extra rule. du steuerst damit ja dann auch ein anderes gerät. das dient meines erachtens dann doch der übersichtlichkleit.

beispiel

rule "Hannes Lichtschalter"
when
    Channel "mihome:86sw1:158dxxx710316:ch1" triggered SHORT_PRESSED or
    Item Hannes_switch2Click changed
then
     if (Hannes_Licht.state == OFF){ 
        Hannes_Licht.sendCommand(ON)
     }
     else {
        Hannes_Licht.sendCommand(OFF)
     }
end

so wäre das meiner meinung nach der sauberste und aufgeräumteste ansatz. einziger negativpunkt ist halt, dass du den on/off status beim taster verlierst. der ist aber sowieso überflüssig. an nem taster kann man den status optisch nicht erkennen. also braucht der auch keinen "software" status.

was steht denn zum tradfri in deinem [definition='1','0']log[/definition] drin wenn du ihn drückst? muss ja auch was mit "triggered ...." sein oder hat der tatsächlich einen on/off status?

tradfri und xiaomi sind doch nur taster oder? die haben dann ja keinen on/off zustand sondern setzen nur einen string ab.
wenn dem so ist, dann wäre die kürzeste variante zwei trigger mit "or" zu nehmen und dann die jeweiligen signale per case auszuwerten. also genau wie du es jetzt schon hast. es muss nur geschaut werden, ob der tradfri auch "SHORT_PRESSED" sendet oder was anderes. wenns was anderes ist dann einfach diesen string per "case" zusätzlich reinnehmen.

das hatte hier jemand schonmal auch gehabt. die verzögerung muss vor "sendTelegram". ich würde aber einen timer anstatt eines threadsleep einsetzen...bspw

rule "aufnahmen"
when
    Item TVH_Aufnahme received command
then
val telegramAction = getActions("telegram","telegram:telegramBot:bot")
    switch TVH_Aufnahme.state {
        case OFF: {
            createTimer(now.plusMinutes(1), [|
            var String aufnahmename = TVH_Letzte_Aufnahme_Name.state.toString
            var String kanal = TVH_Letzte_Aufnahme_Kanal.state.toString
            telegramAction.sendTelegram(123456789, "Hallo, die Aufnahme " + aufnahmename + " auf " + kanal + " wurde gerade abgeschlossen.")
            ])
        }
    }
end

kann ich nicht wirklich was dazu sagen. das letzte mal, als ich hyperion direkt an einem pi betrieben hab ist schon sehr lange her, seinerzeit auch noch die erste hyperion version.
ich hab jetzt schon lange x86 + wemos mit wled in betrieb.
mangels freiem pi kann ich da auch nichts testen um zu helfen.

du musst nichts beachten
- zuerst alles von der alten hyperion version entfernen/deinstallieren
- dann wget -qO- https://git.io/JUvg7 | bash
das hyperionng webif erreichst du dann nach erfolgreicher installation über http://kodi.ip:8090

allen leuten von kodinerds die dir namentlich im installationsprozess angezeigt werden musste übrigens ein bier ausgeben

falls interesse an einer verbesserten version ...
- mehr als 2 personen durch gewichtsfilter (lower then X & greater then Y) identifizierbar
....besteht einfach bescheid geben. Ich lade das dann hoch.

beispiel config:

"USERS": [
        { 
          "GT": 85,
          "LT": 110,
          "SEX": "male",
          "NAME": "Person1",
          "HEIGHT": 180,
          "DOB": "1966-01-01"
        },
        { 
          "GT": 55,
          "LT": 65,
          "SEX": "female",
          "NAME": "Person2",
          "HEIGHT": 180,
          "DOB": "1966-01-01"
        },
        { 
          "GT": 30,
          "LT": 55,
          "SEX": "female",
          "NAME": "Person3",
          "HEIGHT": 100,
          "DOB": "2020-01-01"
        }

Zeitplan geht bei mir per "Digitales Wohlbefinden..." Immer noch. Im Soundmenü seit 12.5 nicht mehr.

also ich komme noch ins menü. bin mittlerweile auf 12.5.7 "Enhanced Edition"
"Digitales Wohlbefinden ...." -> "Bitte nicht stören" -> "Zeitplan für Einschaltzeit"

kein neues thema mit dem gleichen inhalt nur weils oh3 ist. editiere einen verweis zum lösungpost, jeweils oh2 und oh3 in den ersten post.

genau das meinte ich. jetzt passt es

Zitat von patrick31698

Vielleicht kann man die rule auch noch vereinfachen?
Ich habe jetzt gesehen, daß man die Einträge auch einzeln ansehen kann.

na da passt aber noch nicht so alles. bekomme beim api aufruf (mehrere versuche) teils leere oder falsche antworten. von daher lass es erstmal so....zumindest meine empfehlung.
ich habe das jetzt alles bei mir testweise durchgespielt. es läuft alles ferhlerfrei durch und alle sachen werden angezeigt.
was mir bei dir sofort auffällt, du hast in deinen items die du neu angelegt hast keinerlei bezeichnungen drin. ohne die wirds nichts mit der darstellung in der sitemap. im oberen auskommentierten teil ist alles drin.

du musst in den things erstmal deine benötigten sachen anlegen wenn noch nicht erledigt, natürlich auch die channels in der items datei channels anpassen ... siehe da TV Headend Server Status in Sitemap
- TVH_Aufnahmen
- TVH_Aufnahmen_Anzahl
- TVH_Aufnahmen_Zeit
TVH_Aufnahme1, 2 und 3 sowie TVH_Aufnahme1_Zeit, 2 und 3 sind dummy items, die haben keinen channel da sie von der rule (quellen sind "TVH_Aufnahmen"/"TVH_Aufnahme_Zeit" items) mit inhalten versorgt werden

ich kann dir mit code nur helfen, wenn du mir alles postest was du in verbindung mit tvheadend in den openhab dateien drin hast.

Ich hatte natürlich vorrausgesetzt, dass du die Channels auf das neue http Binding angepasst hast

nein da fehlt nichts. solltest du weder am browser noch anderswo was geändert haben versuche mal die auth methoden in der things datei zu ändern. der fehler kommt ja offensichtlich von deinem nas, auf dem tvh und evt auch oh läuft.

BASIC BASIC_PREEMPTIVE DIGEST