Anwesenheitssimulation durch zufälliges Schalten der Lichter

[mad-mike]

Moin.

Die Frage ist berechtigt.
Ähm drauf gucken nie, außer jetzt zur Test Phase.
Diese Anzeige macht ja auch gar kein Sinn in Zusammenhang mit der oben erstellen rule.

Geht mir viel mehr um Lernfaktor. Wie man sich halt mit kleinen Schritten vorwärts arbeitet.

Dieses erstellen von (DSL) rule ist sehr mächtig, im Gegensatz zu diesen Bosch smart zusammen geklicke. Aber es ist auch so, das ich es als Anfänger doch nur schwer verstehe. Am besten versuchen und machen, gucken was passiert.

Verstehst?

[udo1toni]

Gut Lernfaktor ist ist immer eine gute Sache.
Nur im Hinterkopf behalten, dass openHAB nur eine recht überschaubare Anzahl an Aktionen pro Sekunde ausführen kann. Sprich: Wenn Du ein System haben willst, welches agil arbeitet, vermeide Regeln, die sekündlich ausgeführt werden, insbesondere, wenn es mehrere Rules werden, die dies tun.

[peter-pan]

Die Frage ist berechtigt.

Klar man kann die Sinnhaftigkeit mancher Aktionen hinterfragen. Aber es macht halt doch Spass, etwas auszuprobieren .

Das mit dem Count-Down hat mir keine Ruhe gelassen. Und Udo hat ja hier oder in einem anderen Post über die Möglichkeiten von Bash geschrieben.

Ich habe mir deshalb mal ein "kleines" Bash-Script "zusammen gebastelt", das eigentlich nichts anders macht, als von einem bestimmten Wert (Sekunden) auf Null herunter zu zählen.
Dieses Argument wird einfach mit dem Aufruf des Scripts mitgegeben. Also z.B. "./test_count.sh 20", wobei "test_count.sh" der Script-Name ist und 20 die Sekunden. Nicht vergessen das Script auch ausfürbar zu machen
mit

"chmod +x test_count.sh" bzw. "sudo chmod +x test_count.sh"

Code: Alles auswählen

#/bin/bash

## Mqtt-Variablen
mqtt_broker_ip="192.168.178.75"
# mqtt_broker_ip="localhost"
mqtt_broker_port="1883"
mqtt_topic="count/down/countDown"


sec_rem=$1

  if [ $sec_rem -lt 2 ]; then
      echo "$1 is already history !"
      exit 1
  fi

  while [ $sec_rem -gt 0 ]; do
        let sec_rem=$sec_rem-1
#        echo "Seconds: " $sec_rem  # kann zum Testen aktiviert werden
        mosquitto_pub -h $mqtt_broker_ip -p $mqtt_broker_port -t $mqtt_topic/status -m $sec_rem # -d

        sleep 1
  done

##  Just for Fun  ##
sec_rem='LiftOff'
mosquitto_pub -h $mqtt_broker_ip -p $mqtt_broker_port -t $mqtt_topic/status -m $sec_rem # -d

Die Count-Down Werte werden an MQTT (Mosquitto) übergeben. Das Topic habe ich "count/down/countDown" benannt. Da mein Broker nicht auf dem gleichen RasPi läuft wie OH3, habe ich hier die IP-Adresse des Broker-RasPi's angegeben.

Zur CPU-Belastung des OH3-Pi's kann ich nicht viel sagen. Aber ich denke der hat das gut verkraftet (RasPi 3b+).

Um das ganze auch in OH3 darstellen zu können, habe ich noch ein Thing und Items in OH3 angelegt.(Text-Konfiguration).
Achtung:Die Konfiguration des Things ist nach der Methode -Bridge und Things- in seperaten Dateien angelegt.

.things

Code: Alles auswählen

    Thing mqtt:topic:vera:liftoff "Engines startet"  (mqtt:broker:vera )     @ "MQTT2" {
    Channels:
        Type string : start        "Count Down Ticker"     [ stateTopic="count/down/countDown/status"]
    }

.items

Code: Alles auswählen

//                           Count Down                                                                                                                    
Group     gCountDown            "Count Down Clock"                 <lamp_globe_light>      (gEG_Buero)               ["PowerOutlet"]                   
//Switch    CountDownSwitch       "Count Down Switch [%s]"           <light>                 (gCountDown)              ["Switch"]          { channel="mqtt:topic:vera:s2006:power"}        
//Number    CountDownNumber       "Count Down Number [%s]"           <qualityofservice>      (gCountDown)              ["Point"]           { channel="mqtt:topic:vera:s2006:rssi" }         
String    CountDown             "Count Down Ticker[%s]"            <sonoff_s20>            (gCountDown)              ["Point"]           { channel="mqtt:topic:vera:liftoff:start" }  

String    CountDownStart        "Count Down Trigger [%s]"          <sonoff_s20>            (gCountDown)              ["Point"]     

Dann habe ich noch auf eine OH3-Page eine "oh-label-cell" angelegt. Die Optionen sind 10 - 50 Sekunden

Yaml:

Code: Alles auswählen

component: oh-label-cell
config:
  title: Count Down -Test 2
  item: CountDown
  action: options
  actionItem: CountDownStart
  actionOptions: 10,20,30,40,50

und eine DSL-Rule, die über das Item "CountDownStart" aktiviert wird.

Code: Alles auswählen

rule "CountDownTimer"
  when
    Item CountDownStart received command
  then
//    val vTime = "30"     // Version 1
//    executeCommandLine("/bin/bash","/home/hab3/test_count.sh", vTime)  // Version 1
//    logInfo("executeCommand","String - : {}", vTime)                   // Version 1 Log  
    executeCommandLine("/bin/bash","/home/hab3/test_count.sh", receivedCommand.toString)  // Version 2
    logInfo("executeCommand","String - : {}", receivedCommand)                            // Version 2 Log  
end

Ich habe auch noch mit einer weiteren Variante experimentiert(mit der Version1 der DSL-Rule), die evtl. auch funktionieren könnte.

Yaml:

Code: Alles auswählen

component: oh-label-cell
config:
  title: Count Down
  item: CountDown
  action: rule
  actionRule: test-13

Da ich deine Regel nicht ganz verstanden habe, weiss ich auch nicht genau wo deine Werte herkommen (zoff, randomTime, etc).

countdown.jpg

Vielleicht kann Udo auch noch was zu der CPU-Belastung bzw. zu den Möglichkeiten sagen.

Gruss - Peter

Edit: Das Bash-Script sollte besser nicht im Home-Verzeichnis liegen, sondern unter "/etc/openhab/scripts"

[udo1toni]

Es ist relativ egal, ob die Änderung nun durch die Rule veranlasst wird oder durch externe Ereignisse. Man muss sich einfach klar machen, was alles passiert, wenn ein Ereignis eintritt. Hier ist es das Update eines Items. Da sich der Wert des Items ändert, folgt noch ein Changed Ereignis für dasselbe Item. Changed wird standardgemäß in events.log geloggt. Außerdem muss geprüft werden, ob es Rules gibt, die auc received update oder changed triggern. Weiterhin muss natürlich jede Ansicht, die gerade irgendwo im LAN angezeigt wird aktualisiert werden. Keine Anhung, wie viel Code da letztlich ausgeführt wird, aber es kommen sicherlich mehr als 100 Zeilen zusammen, vielleicht sogar über 1000.

Für. Jedes. Einzelne. Ereignis.

Und Wenn man nun mittels sekündlichem Countdown zig solche Anzeigen baut, sind das halt entsprechend viele Ereignisse.
Unter OH2 möchte ich schätzen, dass ein potentes openHAB System in der Lage ist, ca. 50 Rules pro Sekunde abzuarbeiten. Vielleicht kommt man auch auf ein paar mehr oder weniger, wenn die Rules entsprechend komplex im Ablauf sind.
Jeder Zugriff auf den openHAB Bus braucht z.B. viel Zeit, weil entsprechende Unterprogramme gestartet werden müssen. Sobald man einen Itemwert mehr als einmal mit einem anderen Wert vergleichen will, lohnt es sich, den Itemwert in einer Variablen zwischenzuspeichern, der direkte Speicherzugriff ist um Größenordnungen schneller.

[peter-pan]

Für. Jedes. Einzelne. Ereignis.

Du hast ja im Prinzip recht.

So etwas ist sicherlich nicht gedacht um jetzt jeder Regel einen eigen Count-Down zu verpassen, dazu wäre es ja auch nötig, für jeden Count-Down ein eigenes Bash-Script(einschl. MQTT), das entsprechende Thing und die dazu gehörigen Items anzulegen.
Die Ansicht sollte meiner Meinung nach immer aktualisiert werden und wird es zuzm Teil auch; z.B.: Widget-Digital-Clock.

Das Logging für Events habe ich grundsätzlich auf "warn" gestellt, da das nur unnötigen Output auf Platte und ggf. frontail(Platte) erzeugt. Das schalte ich höchstens mal zum Testen an, da man das sich in der Regel im "normalen Betrieb" nicht anschaut. Und da kommen schon mal ein paar tausend Zeilen am Tag zusammen.

Für mich war das einfach eine "kleine Herausforderung" um auch mit dem "Drumherum" (Linux/Bash/Mosquitto/etc.) zu experimentieren und was dazu zu lernen und es hat auch Spass gemacht.

Und natürlich auch um dem OP (@mad-mike) einen Lösungsansatz zu liefern .

countdown.jpg

Es gibt zwar auch noch andere Möglichkeiten für einen Rentner sich zu beschäftigen, aber auch bei den anderen Möglichkeiten (z.B.: beim Wandern) kann man sich Gedanken machen wie man so ein Problem lösen oder ein Ziel erreichen kann.

Es es heisst ja nicht umsonst: Der Weg ist das Ziel

So jetzt hab ich aber genug philosophiert.

.

[mad-mike]

Moin zusammen, mit der Umstellung auf openHAB 4.0.1 gabs mit der Rule eine "Warn meldung""

Vermutlich nur eine Kleinigkeit.

Code: Alles auswählen

var Timer RandomLightsTimer = null
val java.util.concurrent.ThreadLocalRandom random = (new java.util.concurrent.ThreadLocalRandom)

rule "Licht zufällig schalten"
when
    Time cron "0 */7 0-23 * * ?"
then
      if((Abwesend.state != ON))                                                                           // Automatik abgeschaltet?
      return;                                                                                              // Dann Abbruch!
      if((HTTPURLThing_km2.state != OFF))                                                                          // Automatik abgeschaltet?
      return;                                                                                              // Dann Abbruch!     
      if((new java.util.Random()).nextInt(2) == 1)                                                         // Licht zufällig einschalten 50/50
      return;                                                                                              // oder auch nicht...
      var randomLights = random.nextInt(zufall.allMembers.size)                                            // Bestimme eine Lampe aus der Liste
      zufall.allMembers.get(randomLights).sendCommand(ON)                                                  // Licht einschalten
//      logInfo("randomLights","Lampe {} ", randomLights)                                                    // Log Info
//      last.postUpdate(randomLights)                                                                        // Wert in last schreiben
      var Integer randomTime = random.nextInt(7,240)                                                        // zufälligen Wert bestimmen
      logInfo("randomLight","Aus in: {} Sekunden.", randomTime)                                            // Log Info
      zoff.postUpdate(randomTime)                                                                          // Wert in zoff schreiben
      RandomLightsTimer = createTimer(now.plusSeconds(randomTime), [ |                                     // Timer erstellen
      zufall.allMembers.filter[i|i.getStateAs(OnOffType)!=OFF].forEach[j|j.sendCommand(OFF)]               // Ordner zufall OFF
    ])
end

mit dieser Meldung.

Code: Alles auswählen

2023-08-04 20:32:12.222 [WARN ] [e.runtime.internal.RuleContextHelper] - Variable 'random' on rule file 'zufall.rules' cannot be initialized with value 'org.eclipse.xtext.xbase.impl.XConstructorCallImplCustom@785987 (invalidFeatureIssueCode: null, validFeature: false, explicitConstructorCall: false, anonymousClassConstructorCall: false)': An error occurred during the script execution: Could not invoke constructor: java.util.concurrent.ThreadLocalRandom.ThreadLocalRandom()

hat jemand eine IDEE?

Danke und Gruss

[peter-pan]

So wie ich die Fehlermeldung verstehe, kommt die Rule-Engine nicht mit der Konstante "random" klar.

Ich bin da zwar auch nur "Betrachter", aber ist(war) es nicht so, dass hier noch am Anfang ein "Import" erfolgen müsste, z.B.:

Code: Alles auswählen

import java.util.concurrent.ThreadLocalRandom
var Timer RandomLightsTimer = null
val java.util.concurrent.ThreadLocalRandom random = (new java.util.concurrent.ThreadLocalRandom)

...oder so ??!!

[mad-mike]

Code: Alles auswählen

2023-08-05 14:18:21.804 [INFO ] [el.core.internal.ModelRepositoryImpl] - Validation issues found in configuration model 'zufall.rules', using it anyway:

The import 'java.util.concurrent.ThreadLocalRandom' is never used.

The import 'java.util.concurrent.ThreadLocalRandom' is never used.

2023-08-05 14:18:22.285 [WARN ] [e.runtime.internal.RuleContextHelper] - Variable 'random' on rule file 'zufall.rules' cannot be initialized with value 'org.eclipse.xtext.xbase.impl.XConstructorCallImplCustom@1489d0c (invalidFeatureIssueCode: null, validFeature: false, explicitConstructorCall: false, anonymousClassConstructorCall: false)': An error occurred during the script execution: Could not invoke constructor: java.util.concurrent.ThreadLocalRandom.ThreadLocalRandom()

[peter-pan]

Sorry, hab auch ein bisschen daran herum gebastelt und auch immer wieder eine Fehlermeldung bekommen.

Der Fehler scheint in dieser Konstantendefinition zu sein.

Code: Alles auswählen

val java.util.concurrent.ThreadLocalRandom random = (new java.util.concurrent.ThreadLocalRandom)

Ich habe mal etwas gespielt

Code: Alles auswählen

val int random = (new java.util.concurrent.ThreadLocalRandom.current().nextInt(10000))

und dann diese (etwas abgewandelte) Fehlermeldung bekommen:

Code: Alles auswählen

2023-08-05 14:34:57.702 [WARN ] [e.runtime.internal.RuleContextHelper] - Variable 'random' on rule file 'test_zaehler.rules' cannot be initialized with value '<XConstructorCallImplCustom>.nextInt(<XNumberLiteralImpl>)': An error occurred during the script execution: Cannot invoke "org.eclipse.xtext.common.types.JvmType.eIsProxy()" because "type" is null

Es hat den Anschein, dass hier etwas nicht korrekt definiert ist. Eine richtige Syntaxdefinition habe ich aber leider auch nicht gefunden .

Vielleicht hat ja sonst jemand eine Idee

[peter-pan]

Hab doch was gefunden , nämlich hier: https://community.openhab.org/t/generat ... 3/110180/9

Diese Definition gibt keine Fehlermeldung mehr:

Code: Alles auswählen

val java.util.Random random = new java.util.Random()

Das (erste) Logergebnis war dann:

Code: Alles auswählen

2023-08-05 14:55:41.694 [INFO ] [penhab.core.model.script.randomLight] - Aus in: 158 Sekunden.

Aber Ich hatte nur mit einer "Torso-Rule" gespielt, da ich deine Umgebung nicht ganz nachbilden konnte.

Vielleicht hilft das ja weiter.