Beiträge von horschte

Zitat von DaVu

Ansonsten bin ich komplett bei horschte. Kodi soll dann was senden, wenn etwas passiert. Und das geht problemlos über die API.

genau das ist auch mein gedankenansatz. die api funktioniert hervorragend und bietet irre viele funktionen. von daher ist es doch sinnvoller boardmittel zu nutzen als sich eine weitere potenzielle fehlerquelle an board zu holen.
das soll aber trotzdem keine kritik meinerseits an eurer lösung sein. wenn das für euch die bevorzugte lösung ist, dann ist auch alles gut. ich wollte lediglich einen hinweis geben.

Zitat von steff

Ich bevorzuge es auch, wenn etwas pro-aktiv seinen Status dem System mitteilen kann.

bei mir genau eine umgekehrte einstellung ...jede weniger die programme (in dem fall kodi) erweitert werden müssen um aufgaben zu erfüllen, desto besser.

bei openhab bspw gibts ~50 infochannels für verschiedenste kodi informationen. dazu kommen unzählige kommandos die gesendet werden können. nicht nur wiedergabe kann erkannt werden sondern auch der medientyp....filme, serien, musik, tv usw. es sollte also kein problem sein, eine bestimmte szenerie (bspw licht aus bei filmstart) zu erstellen, ohne auf dritte addons wie das o.g. kodi2mqtt zurückgreifen zu müssen. bei den anderen lösungen wie fhem, homeassist usw ist das bestimmt ähnlich.

Andere Systeme kommunizieren komplett per API mit KODi. Damit ist dann nichts weiteres an addons o.ä. seitens KODi notwendig.

Es gibt komplette Lösungen wie openhab, homeassist, fhem usw. Daher wird das Interesse an deinem o.g. Projekt auch sehr gering sein. Da wo dein mqtt Broker drauf läuft, kann ja auch gleich ein komplettes Smarthome System die ganze Arbeit übernehmen.

Ich hab das genau wie du auf dem Screenshot eingestellt. Hab seit langem auch nur noch ein normales Quad LNB. Deine Einstellung ist also in Ordnung und funktioniert bei mir seit Jahren fehlerfrei mit X Clienten, Aufnahmen, pedictive Tuning usw usw..

Zitat von BirdOfPrey

Was ich gemerkt habe, dass die Sitemap (basicUI) bei mir deutlich schneller aktualisiert wird. Früher bei OH 2.5 dauerte es schon mal zwei/drei Sekunden, bis der Status aktualisiert wurde, wenn ein Item extern (nicht über die UI) geschaltet wurde. Das geht bei OH3 unverzüglich.

hab ich bei mir ein gegenteiliges phänomen. daten werden zwar sehr schnell aktualisiert, ab und zu werden am telefon aber icons nicht angezeigt, erst nach einem aktualisieren der seite. das tritt bei internen svgs auf und auch bei externen.

Zitat von BirdOfPrey

Ansonsten habe ich es dann so gemacht, dass ich Items über die grafische Oberfläche anlege und rules weiter als Dateien (in DSL geschrieben).

warum über die grafische oberfläche? ich hab das ja selbst schon getestet. das dauert ja alles länger gegenüber einer textconfig.
rules mach ich auch weiter mit dsl...ich kann die gut lesen und hab keinerlei probleme damit. für anfänger siehts da natürlich anders aus.

Zitat von BirdOfPrey

Den einzigen, gravierenden Nachteil, die Items über die Oberfläche anzulegen, neben fehlenden Copy&Paste, ist für mich die fehlende Möglichkeit ein angelegtes Item umzubenennen. Keine Ahnung, warum man so etwas nicht vorsieht.
Früher ging das mit VisualStudio Code und der globalen Suche ja recht einfach.

na das kann ja nicht beabsichtigt sein. wird sicher noch kommen.

btw...etwas finde ich noch schade. rules delay bei startup gibts nicht mehr (zumindest hab ich nichts gefunden in openhabian). fand ich äusserst nützlich und würde einige fehlermeldungen in meinem [definition='1','0']log[/definition] bei systemstart beseitigen.

bin durch mit der migration zu oh3. nutze weiterhin eine komplette text config. der grafische kram ist mir noch zu suspekt.
die migration war jetzt kein hexenwerk, hatte aber dann doch eine ganze menge fallstricke parat. abgesehen von den veränderten variablen in rules auch diverser anderer kram. das tr064+fritzbox binding muss jemand auf drogen programmiert haben. mir ist selten sowas umständlich konfigurierbares untergekommen (integration anrufbeantworter, wifi-steuerung, telefonanzeigen). man ist natürlich dankbar für das binding, merkt dann aber doch das einige coder mehr kontakt zu nicht-nerds bräuchten um usability zusammenhänge zu erfassen
vorteile gibts für mich persönlich bei oh3 eigentlich kaum welche. vlt die bessere performance, nix zuckt mehr rum beim editieren im laufenden betrieb (bspw in der things datei).
in zukunft wird sich das natürlich sicher etwas ändern, spätestens dann wenn neue geräte dazu kommen. in der binding sparte hat sich ja wirklich einiges getan. bin seit oh1 dabei und fast erschlagen worden, von dem was jetzt alles integrierbar geworden ist.
die neue standardoberfläche....hmmm, kann ich nichts mit anfangen. basicui aus oh2.5 ist für mich übersichtlicher am handy. woanders nutze ich das nie. hängt sicher auch mit der anzahl der eingebundenen sachen zusammen und der präferierten steuerung (bei mir fast nur automatisierungen + sprache).
vlt kann mir ja jemand erläutern was an den neuen features (bspw semantic model) ein musthave ist und auch warum.

so...mittagspause....machts jut nachbarn (würde krömer sagen)

Zitat von darkside40

Leider ist es in unseren Smart Home Subforen in den letzten Monaten etwas still geworden. Aber langsam kommt der Winter, wenn man eh nur in der Bude hockt dann kann man da bestimmt auch mal wieder was machen.

na wart mal ab
sobald ich wieder etwas luft hab (ende september) gehts bei mir auch wieder los. hab mir schon ein paar must-have projekte auf die todo liste gesetzt

minuten brauche ich bei meinen rules wo ich das nutze nicht. in meinem fall also zuviel ungenutzter code. trotzdem danke für diesen lösungsweg.
falls jemand tage ermitteln will (hat sich mit oh3 auch was geändert)
now.getDayOfWeek.getValue() gibt den tag als zahl zurück...bspw 1 für montag
now.getDayOfWeek() gibt den namen des tages zurück....bspw MONDAY

bin gerade wieder dabei ein wenig oh2 -> oh3 migration zu betreiben....noch in einer vm.
ich finde bisher keinen "simplen" ersatz für now.getHourOfDay, also bspw

if (now.getHourOfDay > 6 && now.getHourOfDay < 9) {
        Alexa_Bad_Command.sendCommand("FlashBriefing")
    }

vlt kann mir da jemand auf die sprünge helfen

edit: selbst gefunden:
var stunde = now.getHour()

var stunde = now.getHour()   
 if (stunde > 6 && stunde < 9) {
        Alexa_Bad_Command.sendCommand("FlashBriefing")
    }

Openmediavault läuft 100% auf der Kiste. Nextcloud/Seafile oder was auch immer dann im docker oder nativ rauf

also bei mir wurden die sender mit tvh (sat) auch ohne ausstrahlung gefunden. das beschriebene problem kenne ich nur von ganz früher mit e2 boxen.

wieso nicht die uhrzeit aus deiner datenbank auslesen?

Zitat von rols1

@horschte:
pardon - mein Fehler. Ich nutzte zum Testen das akt. Testaddon. Das Update vom Samstag hatte einen Bug (Linefeed im Titel) im Modul XL. Bitte das Testaddon installieren (Quelle s. Startpost, der Fehler ist dort nicht beschrieben, aber im changelog)..
/R

mit dem testaddon funktionieren die einzelnen clips

könnte mal jemand schauen ob bei ihm die tagesschau in 100 sekunden (unter tagesschau xl) einzelclips (nicht die 100 sekunden sendung) noch gehen? bei mir funktioniert es weder aus widgets noch aus dem addon herraus. fehlermeldung kommt keine, [definition='1','0']log[/definition] kann ich ggf nachreichen.

wenn du was zusammen steuern willst dann pack die beiden sachen in eine gruppe. so musst du in den rules nichts doppelt ausführen.
bei den items in zeile 1 und 2 steht in klammern die zugehörigkeit zur gruppe "Dimmer_Bett", in zeile 3 ist die gruppe angelegt. in deiner rule steuerst du nun die gruppe Dimmer_Bett anstatt das item an.

Dimmer  Bett_seite          "Dimmer Nachttisch" <light>  (Dimmer_Bett) {channel="wifiled:wifiled:D8F15BF6C8E5:color"}
Dimmer  Bett_mitte          "Dimmer Kopfteil"   <light>  (Dimmer_Bett) {channel="wifiled:wifiled:D8F15BF6CA4A:color"}
Group:Dimmer  Dimmer_Bett   "Bettlicht"         <light>

wenn du auf 1 schalten lässt kannst du natürlich nicht um 2 % erhöhen, dann passt es mit den 100 am ende nicht mehr. also entweder auf 2 schalten lassen oder in 1% schritten erhöhen.

deswegen schrieb ich das

Zitat von horschte

optional kann da auch der weckerstatus noch abgefragt werden

PLAY ändert sich auch wenn normal musik wiedergegeben wird. das fällt als trigger also aus wenn du es auch ohne wecker nutzen möchtest.

Zitat von patrick31698

Nur habe ich bisher nichts vernünfitges gefunden, wie man automatisch dimmt.

lässt sich unterschiedlich lösen. ein weg wäre bspw den ersten wert zum dimmer per wecker trigger senden, dann eine rule die bei "lampe changed" triggert und bspw hinter einem timer den wert +1 zur lampe sendet.

beispiel:

rule "langsam hochdimmen"
when
  Item Lampe_Dimmer changed
then
val dimmerwert_aktuell = Lampe_Dimmer.state as Number
val dimmer_steigerung = 2
           createTimer(now.plusSeconds(5), [|
             if (Lampe_Dimmer.state < 100 && Lampe_Dimmer.state > 0) {
                    Lampe_Dimmer.sendCommand(dimmerwert_aktuell + dimmer_steigerung)
             }
           ]) 
end

in zeile 6 steht wieviel % bei jedem schritt hochgedimmt werden soll, in zeile 7 wieviel sekunden pause zwischen jedem schritt. in zeile 8 wird sichergestellt, dass die rule nur triggert solange die lampe nicht komplett aus oder an ist (optional kann da auch der weckerstatus noch abgefragt werden). der wecker trigger muss zum dimmer dann bspw ne 2 senden um den ganzen vorgang zu starten. darauf achten, dass 100 durch deinen wert aus zeile 6 + deinem startwert dividierbar ist. ansonsten hängt die rule in nem loop. abhängig von der response zeit deiner lampe würde ich den timer in zeile 7 nicht zu niedrig setzen!