Posts by maxreiner

    Ist Tasker besser als macrodroid, umfangreicher?

    Tasker ist einfach der Standard bei der Automatisierung unter Android. Deutlich mächtiger als macrodroid, wobei dieses immer mehr aufholt. Ein großer Vorteil von tasker ist auch, dass man damit auch richtige apk's erstellen kann, also geräteunabhängige lauffähige apps. Allerdings erkauft man sich dies mit einer recht unhandlichen Bedienung und aus meiner Sicht (bin nie SW-Entwickler gewesen) ist es wenig intuitiv. Deshalb nutze ich, wenn möglich, macrodroid.



    Wo läuft iobroker bei Dir? was macht Du alles damit, hast Du einen Beispiel?

    Auf einem raspberry pi 4. Neben ioBroker läuft dort auch noch pivccu3 (für hm/hmip-Geräte) und Phoscon (für zigbee-Geräte). Die entsprechende Hardware steckt dort natürlich auch. Wie gesagt, ioBroker ist mein Integrationszentrum, von wo aus alle Komponenten erreichbar sind. Z.B. ist mir letztlich ein innogy-Rollladenschalter gestorben. Also habe ich den auf hmip umgerüstet. Oder: bei innogy gibt es keine vernünftigen Sonnensensoren, bei hmip schon. Also steuere ich meine innogy- Rollladenschalter mit hmip-Lichtsensoren. Die Programmierung von Szenarien habe ich teilweise auch in ioBroker verlagert (Blockly), das entlastet die SHZ und eröffnet neue Möglichkeiten, da dort wesentlich mehr Freiheiten bestehen.

    Neben Livisi (oder eigentlich noch darüber als zentraler Schnittpunkt) ist es ioBroker. Daran hängen Adapter wie:

    - innogy

    - deconz

    - hm-rpc

    - samsung-tizen

    - tr-064

    usw.

    Auf Mobilgeräten verwende ich für diverse Bedienungen, kleine Automatisierungsaufgaben, Anzeigen etc.:

    - vis (ioBroker), als Haupt-Bedienoberfläche

    - macrodroid

    - tasker, wenn eine Funktion in macrodroid nicht zur Verfügung steht

    - kwgt, z.B. für die Außentemperaturanzeige, die aus einem Temperatursensor von hmip stammt

    - http-shortcuts

    - Alexa, hat sich in letzter Zeit immer mehr zum Haupt-UI entwickelt (z.B. "Alexa, gute Nacht": alle lampen aus; Heizung aus; Rollladen zu; prüfen, ob alle Türen und Fenster zu sind)

    Ich habe gestern das update gemacht. Folgende Ausgangssituation:

    Meine SHZ2 liegt eigentlich ungenutzt rum, da ich damals (Anfang vorigen Jahres) aufgrund vieler Probleme entschieden hatte, erst mal wieder auf die alte Zentrale zurück zu rüsten. D.h., seit mindestens 1/2 Jahr hat sie auch kein Update mehr bekommen. Welche Version bis gestern noch drauf war, kann ich leider nicht sagen. Eigentlich hätte ich nach all dem hier im Forum beschriebenen erwartet, dass das neue update Probleme machen würde. Jedoch nichts dergleichen, es lief innerhalb 20-30 Min. durch ohne Meckern.

    Besonderheit war, dass ich die Zentrale vorher noch mal komplett resettet hatte. Vielleicht ist das der Weg, wenn es nicht klappt: Reset - das Update auf die quasi jungfräuliche SHZ aufspielen und danach die Konfiguration vom Server zurückholen?

    Das geht natürlich auch. Ich bin mir auch noch nicht sicher, wofür ich mich am Ende entscheide, der ursprüngliche Plan war, sukzessive alles auf hmip umzubauen.

    Ich habe derzeit, wie gesagt, die 3 Rollladenaktoren, ein paar Tür/Fenstersensoren (optisch), Helligkeits- und Außentemperatursensoren und eine Türklingel-Kontaktschnittstelle von hmip, aber auch etliche zigbee-Teile (smarte Lampen und Schalter) integriert. Das alles spricht über ioBroker miteinander und läuft zufriedenstellend. Der Vorteil von hmip und zigbee ist für mich vor allem, dass es ohne Internet läuft, die Schnittstelle zu Livisi braucht natürlich Internet und da hakelt es manchmal.

    Du reparierst die Geräte (darüber haben wir bereits gesprochen).....willst Du nicht/kannst Du nicht

    - Du besorgst Dir Ersatzgeräte bei Ebay

    - Du wartest, bis die hier angekündigten Nachfolgegeräte (Homematic-IP oder Shelly) verfügbar sind

    - Du wartest nicht, schmeißt LIVISI raus und kaufst was anderes.

    Fehlt noch eine Möglichkeit, die ich in einem ählichen Fall gewählt habe (einer meiner Rollladenschalter zickte rum, C26 war keine Lösung) :

    Du rüstest die Rollladenschalter auf hmip um, in der Hoffnung, dass irgendwann diese in das Livisi-System integrierbar sind. Dazu muss natürlich eine CCU3 her, was aber mit raspberry pi und Sendemodul kein Riesenakt ist. Die Verbindung zum Livisi-System (wenn überhaupt erforderlich) lässt sich mit ioBroker auf dem gleichen raspi leicht herstellen. Der raspi kann später ja auch für etwas anderes hergenommen werden.

    hab's gerade mal probiert eine Variable in ioBroker zu schalten. Klappt wunderbar - auch ohne node-red, wenn ich als URL die ganz normale http-get-Anfrage (bis zum "?")

    z.B.

    "http://pi4-1-iobroker:8087/set/0_userdata.0.Variable.Lampe_einschalten"

    eingebe und als Parameter den Rest, also

    z.B. "value=true".

    Hallo MASTER29F,

    danke für die Beschreibung, ich werde mich bei Gelegenheit mal daran versuchen. Was ich noch nicht ganz begriffen habe: wenn, wie oben beschrieben, der Request nur in eine Richtung ohne Umweg über die Cloud funktioniert, wie kommen dann Rückmeldungen/Bestätigungen/Quittungen zur Befehlsausführung vom Fremdgerät zur SHC zurück? Oder anders gefragt, kann ich Informationen (z.B. Temperaturwerte eines hmpi-Außentemperatursensors) auf diese Art abrufen? Ich habe das bisher immer nur über den innogy-Adapter im ioBroker realisiert, was auch gut geht, solange der innogy-Adapter verbunden ist und lebt. Http-request von livisi aus hab' ich bisher noch nicht probiert, daher meine Ahnungslosigkeit.


    Gruß

    Reiner

    Tolle Idee! Ob so etwas auch mit ioBroker gehen könnte?

    Ich bin vor ca. 2 Jahren von OH weg zu ioBroker, insbesondere weil da (zumindest zum damaligen Zeitpunkt) mit vis wesentlich mehr und vor allem einfachere Möglichkeiten der Visualisierung bestehen. Leider scheint hier bei den "LIVISI-Anhängern" eine größere Affinität zu OH zu bestehen.

    Derzeit laufen bei mir schon einige Anbindungen über http-requests, z.B. zwischen Android-shortcuts und zigbee-, hmip-, aber auch livisi-Geräten, aber im Falle von livisi eben immer über den innogy-Adapter, d.h. über Internet.

    Wenn man, wie in der Fragestellung angedeutet, mehrere Systeme veknüpft hat, dann ist da vielleicht auch ioBroker dabei. Damit würde ich mir dann zutrauen, so eine Aufgabe zu lösen. In diesem Zusammenhang kommt aber ein alter Wunsch von mir wieder ins Spiel: die Variablen im LIVISI-System sollten nicht nur logische sondern mindestens auch String- und/oder Integervariablen sein können. Dann könnte man solche Werte wie z.B. die o. g. Zeiten auch direkt übergeben und nutzen.

    Hatte ich vor ein paar Tagen auch so ähnlich, allerdings war die Verbindung zu allen Geräten unterbrochen. Intern war die Bedienung aber weiterhin möglich (z.B. ließ sich die Temperatur mit dem Raumthermostat einstellen und das kam bei den HKT's auch an). Neustart per Software (in der App) hat nichts gebracht, auch nicht der Wechsel auf die Browserversion. Gelöst habe ich es durch stromlos machen der Zentrale und ca. 10 s Warten. Dannach lief alles wieder.

    Reiner

    Nö, Deine 1. und 2. Regel gehen so nicht: mit ODER können nur Trigger verbunden werden, also z.B. ein Zustand wird geändert oder ein Zeitpunkt erreicht. Ein Zeitraum ist aber eine Bedingung und die kann nur über UND verknüpft werden. Richtig wäre deshalb:

    WENN Zustand auf JA gesetzt wird

    UND Zeitraum = 6:00 bis 21:00

    DANN ZielTemperatur auf 21°C

    Analog dazu mit NEIN:

    WENN Zustand auf NEIN gesetzt wird

    UND Zeitraum = 6:00 bis 21:00

    DANN ZielTemperatur auf 19°C

    Die 3. Regel kannst Du Dir sparen, sofern Du ohnehin ein Temperaturprofil für den Raum programmiert hast, z.B. 6:00 bis 22:00 21°C, 22:00 bis 6:00 19°C.

    Reiner

    Möchte genau dieses Szenario für die Kinder- /Jugendzimmer umsetzen. Mittels ioB...

    Wenn Du das iobroker-Problem schon gelöst hast, ist es doch ganz einfach, vorausgesetzt der Zustand "Zuhause" ist tatsächlich im LIVISI angelegt und nicht nur als Variable in iobroker.

    Dann einfach in LIVISI "wenn Zuhause =ja dann Raumklima xyz=21°C" usw. Oder habe ich das Problem noch nicht verstanden?

    Reiner

    Bei mir hat seit ein paar Tagen auch ein Rollladenschalter gesponnen (weiß gar nicht mehr, wie er genau reagiert hat, jedenfalls weder konsequent "Fahrt mit kurzem Tastendruck" noch "mit langem Tastendruck". Ist auch egal, jedenfalls letztendlich zurückgesetzt und neu eingebunden (mehrmals gemacht, sowohl mit "alten Daten" als auch komplett ausgesondert und neu eingebunden; Fahrzeiten immer korrekt von Hand eingetragen). Das Ergebnis ist immer, dass er zwar normal arbeitet aber nur im Modus "mit kurzem Tastendruck". Die Umstellung auf "mit langem Tastendruck" wird im entsprechenden Szenario einfach nicht angenommen (lässt sich einstellen aber nach Abspeichern ist die alte Einstellung wieder da). Probeweise wollte ich dann mal einen anderen Rollladenschalter (der nicht zurückgesetzt worden war und bei dem die Betriebsart auf "mit langem Tastendruck" steht und auch funktioniert) auf die andere ("kurzer Tastendruck") umstellen: gleiches Verhalten, es wird nichts abgespeichert.

    Habe ich noch etwas übersehen? Vor Jahren (seitdem habe ich die Stelle nicht mehr angefasst) ging das noch problemlos. Ich habe noch Zentrale 1.