Regelfragen und Komisches Verhalten des wifiled Bindings

[hoggle1969]

Hallo.
Ich bin noch blutiger Anfänger mit OH2 (Komme von fhem) und versuche mich ein wenig mit dem System anzufreunden.
Meine Homematic, FS20 und Zwave Geräte sind angelegt und ich habe es auch schon über eine Regel hinbekommen, das ich mein wifiLED-Stripe mit einem FS20 Schalter an- und ausschalten kann. Das selbige mit einem FS20 Schalter und einem Zwave-Wallplug.
Aber jetzt finde ich ein paar Sachen nicht und etwas scheint mir auch ein wenig "komisch" am System zu sein.

Also, erst einmal das "komische":

Wifi LED Binding per Paper-UI installiert und der Stripe wurde erkannt (382A-RGBW). Channels wurden erkannt (Power, Color, White, White 2). In Paper-UI/Control werden mir einige Items angezeigt (Power Switch, Color-, Brightness-, Saturation-, White- und Program-Speed-Slider, sowie ein Pulldown-Menü für die Programmauswahl).

Per Rule schalte ich das Licht an und aus mit einem FS20 Schalter:

rule "Schranklicht_an_wenn_Schalter1_an"
when
    Item Wz_fs20_k1 changed to ON
then
    wifiled_wifiled_ACCF2384DDA2_power.sendCommand(ON)
end

rule "Schranklicht_aus_wenn_Schalter1_aus"
when
    Item Wz_fs20_k1 changed to OFF
then
    wifiled_wifiled_ACCF2384DDA2_power.sendCommand(OFF)
end

So, das als Vorgeschichte (Wir für die Frage mit der Zeit benötigt)
Wenn ich jetzt im Habpanel einen Slider für das Whitelicht einstelle, oder im Controlpanel vom PaperUI den White-Slider bewege, dann kommt im Log folgendes an:

017-12-22 16:36:20.185 [ome.event.ItemCommandEvent] - Item 'wifiled_wifiled_ACCF2384DDA2_white' received command 11

2017-12-22 16:36:20.195 [vent.ItemStateChangedEvent] - wifiled_wifiled_ACCF2384DDA2_white changed from 0 to 11

2017-12-22 16:36:47.100 [vent.ItemStateChangedEvent] - wifiled_wifiled_ACCF2384DDA2_white changed from 11 to 0

Der Slider zieht also nach einer kurzen Zeit wieder auf 0 (Das Licht bleibt aber auf 11. Zauberei???)
Das ist für die Funktion nicht so schlimm, aber für die Visualisierung. Kann ich da irgendetwas ändern?

Oh, bevor ich es vergesse, ich habe gestern meinen RPI3 mit Openhabian v1.4 neu aufgesetzt und über openhabian-config ein Update gemacht, sollte also ziemlich aktuell sein (Openhab 2.2.?)

So, das zum optischen "Problem", jetzt nee technische Frage an die Gemeinde:

Ich habe so einen ELV FS20 Komplettbausatz KSE Funk-Klingelsignalsender, der in fhem sehr gut funktionierte, also, wenn jemand klingelte, dann wurde der oben erwähnte LED-Stripe für ein paar Sekunden Blau und sprang dann zurück auf den Ursprungs-zustand, also aus oder auf die vorher gewesene Farbe.

Den Klingel-Kontakt habe ich in der FS20.items Datei wie den Schalter angelegt:

Switch Wz_fs20_k1    "Wandschalter 1"    {fs20="832700"}
Switch Wz_fs20_k2    "Wandschalter 2"    {fs20="832701"}
Switch Wz_fs20_k3    "Wandschalter 3"    {fs20="832702"}
Switch Wz_fs20_k4    "Wandschalter 4"    {fs20="832703"}

Switch Klingel_1    "Türklingel1"    {fs20="ea9c00"}
Switch Klingel_2    "Türklingel2"    {fs20="ea9c01"}

Wie kann ich jetzt eine Regel erstellen, die, erst einmal den IST-Zustand zwischenspeichert wenn es klingelt, die Farbe ändert, oder noch besser, ein Programm startet (Gibt ein lustiges Strobe-Programm, wo der Stripe schnell flackert) und nach einer gewissen Zeit (So 5 Sekunden) alles wieder auf den Ursprung zurück setzt.

Ach so, es gibt wohl die Möglichkeit, einen Timer zu setzen, aber da würde mir ein Beispiel weiterhelfen

Und da sind wir wohl auch wieder bei dem oben stehenden "komischen" Problem, denn Openhab denkt ja, das der White-Channel auf Null steht.

Am liebsten würde ich beim AN-Schalten über den Schalter auch den definierten Ausgangszustand, also nur das weiße Licht zu ca. 11% anschalten, die Bunten Lichter also auf HSB 0,0,0

Das sollte dann sicher über das Color- und das White-Item klappen, oder?


Ich freue mich auf eure Antworten _{(Und auf Weihnachten)}

[udo1toni]

Ich versuche mal, mich an Deinen Fragen entlang zu hangeln. Deine openHAB Version sollte, so Du die stable Version nach dem 18.12. installiert hast, OH2.2.0.1 heißen.

Paper UI/Control: Vergiss bitte diese Seite. Das ist nicht als normale Bedienoberfläche gedacht. Dort sollten alle Things auftauchen, bei denen mindestens ein Channel zu einem Item gelinkt ist. es sollten dann alle gelinkten Channel angezeigt werden. openHAB linkt nicht alle Channel automatisch, sondern nur die "oft genutzten" (das ist aber eine Festlegung des Binding Programmierers) Du kannst also fehlende Channel nachrüsten, indem Du auf das Thing gehst und die Channel zu mindestens einem Item linkst.

Warum der State des white Channels wieder auf 0 geht... keine Ahnung. Das sollte aber definitiv nicht so sein.

Die Rule zum Zwischenspeichern sollte ungefähr so aussehen:

var DateTime dKlingel = null
var Timer tKlingel = null
rule "Klingel optisch"
when
    Item Klingel_1 received command
then
    if(tKlingel ===null)
        dKlingel = now
    if(tKlingel !==null)
        tKlingel.cancel      
    wifiled_wifiled_ACCF2384DDA2_white.sendCommand(100)
    tKlingel = createTimer(now.plusSeconds(5), [
        wifiled_wifiled_ACCF2384DDA2_white.sendCommand(wifiled_wifiled_ACCF2384DDA2_white.historicState(dKlingel).state as Number)
        tKlingel = null    //wird eventuell nicht gebraucht, die Timer Variable sollte eigentlich automatisch auf null gehen (entweder verifizieren oder einfach selbst auf null setzen)
       dKlingel = null    //wird nicht unbedingt gebraucht, da null keine Bedingung ist
    ])
end

Dieser Code ist ungetestet, vermutlich wird er Fehler enthalten. Wichtige Voraussetzungen sind:

1. es ist eine Persistence aktiv, die frühere Werte des Items zurückliefern kann (Speicherregel ist mindestens everyChange)
2. das Item hat zum Zeitpunkt des Klingelns einen gültigen Zustand.

Was macht der Code im Einzelnen?

1. es wird eine dateiweite Variable für einen Zeitstempel definiert und mit null initialisiert
2. es wird eine dateiweite Variable für einen Timer definiert und mit null initialisiert
3. Wenn die Klingel auslöst, triggert die Rule
4. es wird überprüft, ob der Timer läuft. Wenn nein, wird die aktuelle Zeit als Zeitstempel gesetzt
5. Falls ein laufender Timer existiert, wird er entfernt
6. Das Licht wird auf volle Helligkeit geschaltet
7. ein Timer wird gestartet, Zielzeit ist die aktuelle Zeit plus 5 Sekunden
8. Die Rule wird beendet.

Wird die Rule während des Timerlaufs erneut getriggert (ungeduldiger Besucher), wird kein neuer Zeitstempel gesetzt, aber der Timer wird gelöscht und neu angelegt.

Läuft der Timer ab, wird der Wert aus der Historie des Items geholt, und zwar zum Zeitpunkt, als das Licht noch nicht geändert war. Diese Helligkeit wird an das Item gesendet.
Anschließend werden die Variablen auf null initialisiert.

Du musst natürlich für jede Eigenschaft (Farbe, Helligkeit, Sättigung) eine weitere .sendCommand Zeile einfügen, sowohl vor der Rule (Klingel signalisieren) als auch im Timer Rumpf (alten Zustand wiederherstellen). Alternativ kannst Du ein Color Item verwenden und dieses verwenden. Der Typ ist dann HSBType.

Für den Strobe Effekt könntest Du den Befehl executeCommandline() verwenden. Natürlich solltest Du dann entweder beim Aufruf schon eine Dauer übergeben, oder mit einem weiteren Aufruf das Strobe wieder stoppen, bevor Du den alten Zustand wiederherstellst.

Die passende Rule für Einschalten hast Du ja schon, Du musst dort nur die sendCommand Befehle entsprechend anpassen. Für Color sieht das dann so aus:

MyItem.sendCommand(new HSBType(hue as Number,sat as PercentType, bri as PercentType))

wobei (0,0,0) sicher funktionieren sollte.

[hoggle1969]

Okay,
das ist mal eine Antwort auf alle gestellten Fragen..... (Wirklich, sehr Lieben Dank dafür)

.... aber jetzt stehe ich mit neuen Fragen hier, obwohl mir die schon länger im Kopf rum schwirren.
Ich habe durch mein Schulenglisch und durch Jahrelanges arbeiten mit Computern das ein oder andere behalten und konnte mich so ein wenig in Openhab einarbeiten.
Um mal ganz vorsichtig ein Thema für meinen Wechsel zu OH2 anzusprechen. In fhem kam es mir so vor, als wenn man ein Informatikstudium absolvieren müsse, um die Systematik und die Abläufe zu verstehen und an die Oberfläche möchte ich erst garnicht denken. Der große Vorteil war aber die sehr große "DEUTSCHE" Community und eine vielzahl von Tutorials und guten Erklärungen.
Die Grundlagen wurden zentral in einem "Erste-Schritte" PDF untergebracht und das war zu Beginn eine große Hilfe.
Bei Openhab ist das etwas anders. Die Installation und die Konfiguration ist super dokumentiert und erklärt, aber dann wird es schnell "dünn".
Und damit zu meinem Thema zurück. Seid ich mit Openhab experementiere (Gestern neu aufgesetzt, davor bis zur Zerstörung meiner SD-Karte schon ein paar Wochen mit Openhab 2.1.) habe ich mich gefragt, wie ich Werte protokolliere.
Okay, es muss eine "Persistence" her. Mhh, da schau ich doch einmal im offenen Openhab-Forum vorbei und stelle fest, das man diese Persistence unter Add-Ons einfach nachinstallieren kann...
... Toll, welche nehme ich denn am Besten? InfluxDB, MariaDb, Mysql, oder rrdj (Die löscht mit der Zeit ältere Daten und fasst die zu Durchschnittswerten zusammen????)...

Aber das schlimmste an der Auswahl ist: Ich weis gar nicht ob ich die dazugehörige Datenbank ebenfalls installieren muß, damit die Daten gespeichert werden und wenn ja, wo wird so etwas erklärt?

Ich meine das geschriebene absolut nicht Böse oder so (Manchmal versteht man etwas geschriebenes anders, als wenn man es gesagt bekommt). Aber so einen Leitfaden, wie die Grundlagen funktionieren wäre schon super. Das protokollieren von Daten gehört für mich mit zu denen.

Boah, was für ein Roman.

Also, ganz kurz und knapp: Wo kann man sich mal etwas schlau zum Thema Persistence und der Konfiguration/Installation lesen?

Aber das Beispiel hilft mir schon super weiter. Vielen, vielen Dank noch einmal dafür.

[zukunftathome]

Hallo Hoggle1969,

zum Thema rrd4j Datenbank (Round Robin) habe ich einen kleinen Artikel mit Anleitung unter: http://zukunftathome.de/rrd4j-datenb...ab-aktivieren/ geschrieben.
Ich persönlich bin ein großer Fan dieser Art der Datenspeicherung. Wie du richtig sagst werden hier nicht alle Daten ewig gespeichert. Je älter die Daten, desto weniger Datenpunkte sind erhalten. Für das Anzeigen von Diagrammen oder dem Speichern eines Schalterstatus ist es perfekt. Positiver Nebeneffekt: Die Datenbank bläht sich nicht unnötig auf.
Viele Grüße
Patrick

[udo1toni]

Ja, das Thema Persistenz ist (wie so Vieles bei openHAB) im Fluss.

Ohne allzu weit auszuholen, versuche ich mal, die Historie zu beleuchten:

Ursprünglich gab es mal rrd4j, db4o und log. Diese Dienste wurden mit openHAB mitgeliefert und mussten "nur" konfiguriert werden. rrd4j hat den Charme, dass die gespeicherte Datenmenge nicht wächst, man muss sich darum einfach nicht kümmern. Der Nachteil ist zum einen, dass rrd4j (zumindest unter openHAB) nur numerische Werte speichern kann, zum anderen sinkt die zeitliche Auflösung, je älter die Daten sind (und es gibt eine Grenze, nach der die Daten einfach verschwinden). db4o kennt keine Einschränkungen des Datentyps, dafür wächst die Datenbank aber (theoretisch) ins Unendliche, je länger das System läuft. Die Logging Persistence konnte nur schreibend verwendet werden, openHAB konnte diese Daten also nicht selbst verwenden.

Es gab (kram im Gedächtnis) noch MongoDB, aber da hätte man auch schon etwas dazu installieren müssen.

Nun ist es bei Enthusiasten nicht unüblich, dass sowieso schon eine Datenbank auf einem Rechner läuft. Es bietet sich also an, diese für openHAB verfügbar zu machen. Da es etliche populäre Systeme gibt, gab es dann auch etliche Persistence Services, die aber alle auf jdbc (Java DataBase Connectivity) zurück griffen. da lag es dann nahe, die gemeinsam unter einem Persistence Service verfügbar zu machen - dass jemand mehrere verschiedene Datenbanksysteme betreibt (und in jedem openHAB Daten sehen möchte) ist eher unwahrscheinlich.
Und dann kam jemand, dem die Graphen aus openHAB nicht so gut gefielen. Also hat er Grafana verwendet, um hübschere Graphen zu erhalten. Zu dem Zeitpunkt konnte Grafana aber noch nicht mit beliebigen SQL Datenbanken umgehen, dafür aber mit influxDB, welches auf Zeitreihen optimiert ist. Also wurde auch influxDB als möglicher Persistence Service dazu erfunden.

All diesen Lösungen gemein ist aber, dass die Database Engine nicht mit openHAB mitgeliefert wird. Wer openHABian in der aktuellen Version nutzt, kann aber komfortabel auch diverse DB Engines installieren. Ob es sinnvoll ist, das auf einem Raspberry zu tun, sei mal dahingestellt (Stichworte SD-wearout, Systemlast), aber es geht.

Ach ja, fast vergessen: Google Calendar ist auch (wieder) mit dabei. Damit kann man prima eine Anwesenheitssimulation erstellen. Das Haus "merkt" sich im Google Calendar was so passiert, und wenn man in Urlaub geht, werden die Ereignisse vor z.B. 14 Tagen wiederholt. Das ist besser als regelmäßige Programme (kann man leicht als Automatik erkennen) und wesentlich besser als zufallsgesteuerte Ereignisse, denn es gibt trotz allem typische Muster im Tagesablauf, die der Zufallsgenerator nicht ohne erheblichen Aufwand erzeugen kann (Analyse plus Regelwerk). Dass jemand über mehrere Wochen genau Buch führt und dann bemerkt, dass der Ablauf vor 2 Wochen der Gleiche war, ist eher unwahrscheinlich.

Für die geforderte Funktion (merke Dir, was vor 5 Sekunden war) ist rrd4j prima - Zahlen gehen gut und ON/OFF wird als 1/0 umgesetzt, wenn ich mich richtig erinnere. Da muss also nichts zusätzlich installiert werden.
Die Konfiguration ist recht einfach, aber es gibt auch einige Knackpunkte.

1. den Persistence Service installieren
2. den Persistence Service als default definieren (in Paper UI oder über die runtime.cfg)
3. den Persistence Service konfigurieren (im Fall von rrd4j muss man nicht zwingend etwas konfigurieren, die Vorgaben sind ganz gut - man könnte aber z.B. die Aufbewahrungszeiten und die verschiedenen Abschnitte konfigurieren. Ich hab mich damit noch nicht beschäftigt.)
4. konfigurieren, welche Items persistiert werden sollen, indem man (im Fall von rrd4j) eine Datei rrd4j.persist im Konfigurationsordner ./persistence/ anlegt, mit dem Inhalt:

Strategies {    
    everyMinute : "0 * * * * ?"
    default = everyChange
}  
Items {          
     wifiled_wifiled_ACCF2384DDA2_white, wifiled_wifiled_ACCF2384DDA2_hsb : strategy = everyMinute, everyChange, restoreOnStartup
}

Man kann entweder einzelne Items persistieren, oder die Items, die persistiert werden sollen einer Gruppe zuordnen, dann kann man die Gruppenmitglieder persistieren lassen. Du könntest also eine Gruppe wifiled erstellen, bei allen Items diese Gruppe mit angeben, und dann die Items so angeben:

wifiled* : strategy = everyMinute, everyChange, restoreOnStartup

Der Stern bedeutet: "Nimm statt des Items selbst alle untergeordneten Items und persistiere diese.", der Wert von wifiled selbst wird also nicht persistiert, stattdessen alle Einzelwerte. Der * ist kein Platzhalter für beliebige Zeichenketten (das wird gerne mal verwechselt). Wenn der * komplett alleine steht, werden alle Items persistiert (das ist mit Vorsicht zu genießen - Datenmenge, Kompatibilität zum Service usw.).

Das Schlüsselwort restoreOnStartup bewirkt, dass openHAB sich den letzten gültigen Wert aus seinem Gedächtnis holt, wenn es gestartet wird. Damit wird also verhindert, dass das Item einen ungültigen Wert (NULL) enthält.

Wenn man mehrere Persistence Services nutzt, muss man openHAB mit auf den Weg geben, aus welcher Quelle es sich bedienen soll, falls es nicht der Default Service sein soll. (nur so für den Hinterkopf...)
Ich kann nur Romane... wäre ich doch Schriftsteller geworden

[Sefina]

Also das mit dem Englisch ist echt grausam,

du musst viel suchen und alles zusammenbasteln und danach weiter Probieren.

Es gibt zwar eine große deutsche Com diese ist aber im Offiziellen Forum und schreibt englisch .....

MfG

[hoggle1969]

So blöd es klingt: Dank Chrome lasse ich mir die Forenbeiträge ins deutsche übersetzen, nur wenn der Text so überhaupt keinen Sinn macht, schalte ich auf English zurück

Vielen Dank für eure Antworten. Wie gut, das jetzt Weihnachten ist und ich zwischen den Tagen frei hab. Da werde ich mich mal wieder etwas intensiver mit OH2 beschäftigen. Wenn die "einfachen" Sachen laufen (Klingel/Licht; Alexa; Flurbeleuchtung; Garagentor), dann werde ich mich mit den Rollläden befassen. In fhem gab es eine tolle Ergänzung, um Rollläden in Abhängigkeit zur Himmelsrichtung, Tageszeit und Lichtverhältnissen zu steuern (Da trauert sogar meine Frau hinterher). Wenn Fenster- und Türkontakte vorhanden sind, wurde diese berücksichtigt (Rollladen fahren im Sommer nur dann runter, wenn es entweder ca. 20 Minuten (Per Random variabel) nach Sonnenuntergang ist UND die Tür geschlossen, oder die Sonne so stark scheint UND die Temperatur so hoch ist UND die Tür geschlossen ist. Wenn das Fenster gekippt ist, dann fährt der Rollladen in eine Belüftungsposition. Wenn sich der Status des Fensters ändert, also man im Sommer von der Terrasse zurück ins Haus geht und die Tür verschließt, dann fährt auch die Terrassentür zu.

Aber bis ich so weit bin wird es noch ewig dauern. Ich werde erst einmal klein anfangen (Leider ist die Lernkurve bei weitem nicht so steil wie ich es mir erhofft hatte).

Ach noch etwas: Ich habe im Moment einen Laptop (Ubuntu) mit 2 Monitoren, wo auf dem einem die ganze Zeit der Log-Viewer läuft und auf dem 2. das PaperUI. Auf meinem 2. Rechner (Windows) habe ich den Smarthome-Designer und einige (Ich glaube, gestern waren es 5-6) Browserfenster mit Foren, Blogs und Tutorials geöffnet. Irgendwie kommt es mir vor als wenn man bei Openhab auf mehr Baustellen als bei fhem herumtanzen muß, oder sehe ich das falsch?

Egal, jetzt wird erst mal der Monsterbaum geschmückt und dann schaue ich mal, ob ich ein wenig Weihnachtslicht mit Openhab und den LED-Stripes hin bekomme.

Euch allen schon einmal Frohe Weihnachten, einen guten Rutsch wünsche ich erst später. Mir fallen bestimmt noch einige "Sachen" ein.

[hoggle1969]

Hallo Hoggle1969,

zum Thema rrd4j Datenbank (Round Robin) habe ich einen kleinen Artikel mit Anleitung unter: http://zukunftathome.de/rrd4j-datenb...ab-aktivieren/ geschrieben.
Ich persönlich bin ein großer Fan dieser Art der Datenspeicherung. Wie du richtig sagst werden hier nicht alle Daten ewig gespeichert. Je älter die Daten, desto weniger Datenpunkte sind erhalten. Für das Anzeigen von Diagrammen oder dem Speichern eines Schalterstatus ist es perfekt. Positiver Nebeneffekt: Die Datenbank bläht sich nicht unnötig auf.
Viele Grüße
Patrick

Hallo Patrick.
Ich habe gerade mal versucht, das rrd4j Persistence über die Paper-UI zu installieren.
folgende Fehlermeldung kam:

 
    
2017-12-23 12:36:46.933 [ERROR] [core.karaf.internal.FeatureInstaller] - Failed installing 'openhab-persistence-rrd4j': Error:

Error downloading mvn:org.openhab.persistence/org.openhab.persistence.rrd4j/1.11.0

Was kann ich denn bei einem Klick auf Install falsch machen?

[zukunftathome]

Hm, das ist etwas seltsam. Bist du auf dem neusten Stand was die Pakete angeht? Wenn du dich über die Konsole per ssh einloggst müsstest du die Pakete auf den neusten Stand bringen. Auf dem Mac mache ich das über

sudo apt-get update

. Alternativ kannst du auch in die Config von openHAB gehen (sofern du openHABian auf dem Raspberry installiert hast) und das dort anstoßen. Dazu

sudo openhabian-config

eingeben. Das Fenster sieht dann so aus wie im Anhang gezeigt.

Ich hoffe das hilft ein bisschen weiter. Ich hatte bei der Installation der Persistence keine Fehlermeldung dieser Art.

[udo1toni]

hoggle1969 Hast Du openHAB schon mal zwischendurch neu gestartet?

Wenn Du die aktuelle stable Version openHAB2.2.0.1 verwendest, ist es das Einfachste, VSCode als Editor mit dem openHAB Plugin zu verwenden. Bis auf die Browserfenster zur Recherche hast Du da alles in einem Programm Keine Angst, VisualStudioCode hat bis auf den Namen wenig bis nichts mit Visual Studio zu tun. Dieser Editor ist OpenSource von Microsoft unter der MIT Licence. Es gibt ihn für Windows, OSX und Linux. Plugins lassen sich direkt aus VSCode heraus installieren.
In der aktuellen Version unterstützt VSCode auch LSP und kann damit den Code direkt auf dem openHAB Server überprüfen, mögliche Befehle anzeigen, in die Doku verlinken und auch jederzeit Things und Items anzeigen (inclusive automatische Übernahme in den Code)

Den Smarthome Designer kannst Du getrost vergessen, da er abgekündigt ist und nicht mehr weiter entwickelt wird.

Was die dynamische Steuerung der Rollläden betrifft, ist all das, was Du beschreibst problemlos möglich.
Für den Sonnenstand brauchst Du das Astro Binding. Du kannnst dort auf verschiedene (unter anderem Sonnen-) Auf- und Untergänge triggern lassen. Dabei kannst Du auch Ober- und Untergrenzen definieren (also frühestens und spätestens).
Falls Du keine Außentemperaturfühler hast, kannst Du das Weather Binding verwenden, um die ungefähre Temperatur zu erhalten.

Allerdings gibt es kein Modul, um das alles automatisch zu verwursten, stattdessen musst Du die eine oder andere Rule erstellen, um dann alles miteinander zu verknüpfen.

[Sefina]

Wobei ich selbst noch mit meinen Rolladen kämpfe ....

Da es Zeit gesteuert ist ist es Wichtig so wenig latenzen wie Möglich zu haben aber da teste ich noch.
Was ich noch sagen kann, eine Rule datei sollte nicht zu groß sein.
Lieber viele kleine ....

MfG

[udo1toni]

eine Rule datei sollte nicht zu groß sein.

Mir wäre jetzt kein Grund dafür bekannt, allenfalls der Designer mit seiner mangelhaften Reaktionsfähigkeit schon bei relativ kleinen rules-Dateien (Fehleranzeige, Codeergänzung) wäre hier ein echter Grund.
Da der Designer schon abgekündigt ist und der Nachfolger VSCode dieses Problem nicht hat, würde ich die Dateigröße nicht (mehr) als kritisch betrachten.

[Sefina]

Ich habe vor einigen Tagen oder Wochen eine Frage geschrieben das die Rule macht was sie will, Antworten gab es nur eine aber der Fehler hat das Problem nicht behoben .....

Also gehe ich davon aus das es mit der Rule Länge zu tun hat.

MfG

[hoggle1969]

Als erstes einmal "Frohe Weihnachten" an alle Foren-LeserInnen. Hoffentlich habt ihr ein paar ruhige Tage im Kreise eurer Lieben.

Ich bin im Moment noch weit von einer "zu großen" Rules-Datei entfernt, aber das liegt noch an meiner Denkweise. Noch versuche ich mit "realen" Things und Items zu arbeiten, aber das wird wohl kurzfristig nicht weiterhelfen. Wenn ich das richtig verstehe, dann werden bei einigen "Sachen" schnell virtuelle Schalter und Dummys benötigt um "Zwischenergebnisse" zu speichern. Mal sehen. Als nächstes gehe ich jetzt erst mal die Persistenzen an, da ich bunte Charts liebe, speziell wenn es um Temperaturen und Helligkeit geht, da ich die ja für meine Rollladen benutzen will.
Übrigens, das ich die RRD4J Persistenz nicht installiert bekam, lag wohl daran, das ich vorher über openhabian-config die InfluxDB mit Grafana installiert hatte und dabei wohl etwas schief gelaufen ist. Ich konnte auch keinerlei System-Updates mehr machen. Erst nach einer Deinstallation der beiden Programme ging alles wieder und rrd4j war auf einmal fehlerfrei installiert.
Ich forsche mal weiter, hab ja noch etwas Zeit, bis es heute Abend Feuerzangenbowle gibt

[hoggle1969]

Mal eine andere Frage:
Das Thema Items und deren Namen beschäfftigen mich noch sehr.
Wahrscheinlich habe ich zu viele Sensoren und Schalter zugleich angelegt, aber dadurch das ich vorher fhem nutzte, waren sie halt vorhanden und wurden auch alle fast automatisch angelegt.
Durch den "Simple Mode" war das hinzufügen von Items auch mehr als einfach. Leider scheint das im nachhinein doch zu einfach gedacht zu sein.
Ich möchte zum Beispiel den Hellingkeitswert meines Lichtsensors per rrd4j speichern.
Wie ist da jetzt die grundlegende Vorgehensweise? Aus meiner primitiven Anfängersicht klicke ich im Paper-UI auf Control und alle Things stehen dort, auch mein Sonnensensor:

 [h=3]Sonnensensor[/h] Funk-Helligkeitsensor für Außenmontage (HM-Sen-LI-O)

Da drunter steht

Maintenance
Niedriger Batteriestatus [h=2]Luxmeter[/h]  [h=2]1165.38 LUX[/h]

Mhh, ist jetzt "LUXMETER" das Item?

Glaub ich nicht, also rechts neben dem Thing auf den Link zur Config-Seite geklickt.

Da gibt es dann die Channel - Okay, sind Channel und Items das Gleiche?
Auf jeden Fall gibt es da wieder den Punkt Maintenance und Luxmeter und unter dem Punkt Luxmeter den Channel:

Luxmeter [h=3]Lux[/h] homematic:HM-Sen-LI-O:240f1b46:OEQ0229791:1#LUX
Number

Ihr merkt, ich stehe noch am Anfang meines Schaffens.

Ein Thing ist mir verständlich, es ist also ein Gerät, was Eigenschaften hat, aber sind die Eigenschaften Channel oder Items? Könnt ihr mir helfen?