Posts by griffix

Steht so auf der Einführungsseite vom lokalen SH:

Also: Ja, die laufen heute schon lokal auf deiner Zentrale und dabei bleibt es auch

Quote from wadipfadi

Nun zu meiner Frage: Wie kanne ich mein Smart Home auch in Zukunft weiter nutzen ,sowie die Steuerung und Überwachung von überall von unterwegs darauf zugreifen.

Das Thema Fernzugriff nach dem 1. März 2024 wird tatsächlich noch nirgendwo behandelt - LIVISI da solltet ihr nacharbeiten.

Entweder Du machst es wie von winni erwähnt per VPN, oder Du verwendest ein zusätzliches System (OPENHAB, IOBROKER oder HOMEASSISTANT) auf bspw. einem Raspberry Pi.

Zur Einrichtung von OpenHab gibt es eine von Tupper eine Anleitung: SHC MIT OPENHAB 3 IN DIE CLOUD BRINGEN (MYOPENHAB UND ALEXA) ANFÄNGERGUIDE.

Quote from Master71

Ich gehe davon aus das die Zulassung damit erloschen ist. Es sei denn man kann den Antennengewinn und die Sendeleistung in der Zentrale anpassen.

Kannst Du denn etwas zu der Abstrahlrichtung sagen?

Quote from Ralph

Ich habe mich dafür entschieden, an den SHC eine Außenantenne zu montieren.

Im Grunde genommen geht es mir im diesem Thread ja darum herauszufinden, ob es eine optimale Ausrichtung der Zentrale gibt.

Quote from Ralph

Wenn ich mich richtig erinnere, wolle msagner auch mal einen solchen Assistenten schreiben, der aus der LIVISI-Konfiguration Things und Items macht....

Ja, das habe ich auch so im Kopf, aber habe da auch nichts neues drüber gelesen.

Wenn ich so drüber nachdenke, halte ich für Anfänger die Einrichtung von myopenHAB noch schwieriger, da Du dafür die UUID und das Secret aus den Dateien ziehen musst. Das müsste man also am besten auch integrieren.

Hallo liebe OpenHab User und Developer ,

ich habe das mal eine Frage und würde gerne eure Meinung wissen:

Angenommen man wöllte einen Wizard bauen, der Anfängern den Umstieg auf OpenHab erleichtern würde (Verbindung mit SHC & OpenHab, Erstellung aller Things und Items in OH analog zu Livisi, Einrichtung myopenHAB, usw.), was wäre das bessere Ergebnis?

Ja, ich spiele mit dem Gedanken und habe mit ein paar Tests angefangen - aber die Entscheidung, ob Dateibasiert oder über UI (programmiertechnisch API) ist relevant...

Danke für eure Antworten

Quote from Wilson84

Kann mir jemand helfen, wie ich das Problem lösen kann? Muss ich mir eine neue Zentrale zulegen? Vielen Dank für eure Hilfe!

An deiner Stelle würde ich mich einfach mal freundlich an SMARTHOME.SERVICE@LIVISI.DE wenden.

Da ich mir jedesmal einen Wolf suche und es zu den OpenHab Community Beiträgen seit OH 3 Abweichungen gibt, wollte ich euch hier kurz erklären, wie ich es mit meiner Installation (Raspberry Pi mit openHABian) hinbekommen habe.

Warum möchte man das überhaupt haben?

• Irgendwas läuft nicht sauber und man möchte das ganze System neu starten
• Man hat relevante Dinge in OH geändert und möchte nur den OpenHab Dienst neu starten
• Ein Binding hat sich aufgehängt und man muss es neu starten
• ...

Man kann sehr viel umsetzen und auch beispielsweise Regeln erstellen, die ein Binding neu starten, wenn die Verbindung zu dem entsprechenden Dienst verloren ging.

Sicherung, SSH?

Vorab: Erstelle eine Sicherung der SD-Karte.

Dann musst Du dich per SSH mit einem Rechner auf dem OH läuft verbinden (erkläre ich hier nicht, denn wenn Du dies nicht kannst, solltest Du das hier besser nicht machen). Verwende den openhabian Benutzer (falls Du das Standardpasswort nicht geändert hast, es lautet auch "openhabian" - aber ändere es bitte!).

Reboot, Shutdown, Neustart OH

1. Führe folgendes Kommando aus um den openhab Benutzer (als welcher OH ausgeführt wird) sudo Rechte zu geben: sudo adduser openhab sudo
2. Starte visudo um die Rechte des Benutzers zu ändern und die Ausführung von Kommandos ohne Passwortabfrage zu ermöglichen : sudo visudo
3. Nun musst Du der Datei die folgende Zeile hinzufügen (am besten oberhalb der includes). Das Speichern erfolgt über die Nachfragen nach Eingabe von Strg+X. Speicher ohne dem Anhang ".tmp".

# Allow openhab user to execute shutdown, poweroff, and systemctl commands
openhab   ALL=(ALL) NOPASSWD: /sbin/shutdown, /sbin/poweroff, /bin/systemctl, /sbin/reboot, /usr/bin/ssh

Das war es schon... fast... Um in OpenHab jetzt einen Reboot/Shutdown durchführen zu können, legst Du am besten Items vom Typ Switch an mit welchem du die entsprechenden Aktionen auslöst.

Hier ein Codebeispiel:

rule "System Reboot"
when
    Item HealingRebootServer changed to ON
then
    executeCommandLine("sudo","reboot")
end

rule "System Shutdown"
when
    Item HealingShutdownServer changed to ON
then
    executeCommandLine("sudo","poweroff")
end

rule "Openhab Reboot"
when
    Item HealingRebootOpenhab changed to ON
then
    executeCommandLine("sudo","systemctl","restart","openhab.service") 
end

Neustart von Bindings

Falls Du Bindings neustarten können möchtest, muss man weitere Schritte gehen:

1. Wechsel mit cd nach /home/openhabian/
2. Erlaube dem Benutzer das Schreiben in dieses Verzeichnis (warum auch immer das nicht möglich ist): chmod 777 /home/openhabian/
3. Erstelle für den openhab Benutzer einen Schlüssel. Bei der Nachfrage nach einen Kennwort, bitte "keins" auswählen: sudo -u openhab ssh-keygen -t rsa -f openhab.id_rsa
4. Kopiere den Schlüssel aus /home/openhabian/openhab.id_rsa.pub. Den Anfang "ssh-rsa " und das Ende "openhab@openhabian" weglassen.
5. Füge den Schlüssel als neue Zeile unterhalb der Kommentare in die Datei /var/lib/openhab/etc/keys.properties ein. Vorne kommt ein "openhab=" und hinten ",_g_:admingroup" dazu. Die neue Zeile sieht verkürzt dann etwa so aus: openhab=AAAAB {...} yqOCrAK8=,_g_:admingroup
6. Falls das folgende Kommando ohne Passwortabfrage ausgeführt wird, hast Du es geschafft: sudo -u openhab ssh -p 8101 -i /home/openhabian/openhab.id_rsa openhab@localhost. Eventuell kommt hier eine Nachfrage, ob der Rechner vertrauenwürdig ist... antworte mit "yes".
7. Um ganz sicher zu gehen kannst Du noch mit sudo su zum Superuser werden, dann mit su openhab zum openhab Benutzer wechseln und das Kommando ssh -p 8101 -i /home/openhabian/openhab.id_rsa openhab@localhost ausführen. Auch dies sollte ohne Passwortabfrage möglich sein.

Auch hier gibt es ein kurzes Codebeispiel:

rule "Reboot Livisi"
when
    Item HealingRebootLivisi changed to ON
then
    executeCommandLine("sudo","-u","openhab","ssh","-p","8101","-i","/home/openhabian/openhab.id_rsa","openhab@localhost","bundle:restart","org.openhab.binding.livisismarthome")
end

rule "Reboot OH Cloud"
when
    Item HealingRebootOhCloud changed to ON
then
    executeCommandLine("sudo","-u","openhab","ssh","-p","8101","-i","/home/openhabian/openhab.id_rsa","openhab@localhost","bundle:restart","org.openhab.io.openhabcloud")
end

Viel Spaß damit

Quote from MKR

Wenn man sich seine VK-Zahlen anguckt, dann hat der fast 4000 RST2 und 3000 RST nur in der Bucht verkauft 😳 am Amazonas bestimmt noch Mal so viel🙈

wo hast Du die Zahlen her? Edit: schon selbst gefunden...

Das ist vermutlich der größte Zuwachs an Geräten die das System innerhalb der letzten Jahre erlebt hat

Quote from PhilippPB

Wie sieht es eigenlich aktuell mit den HKTs aus, die Kesenci verkauft? Da steht neuerdings "nicht über die App programmierbar".

Schreibt der das da nur hin da man sich als Neukunde bei Livisi nicht mehr registrieren kann oder sind das wieder Geräte, die eigentlich nicht verkauft werden sollten?

Ich vermute auch mal, dass er sich absichern möchte. Livisi schrieb zwar, dass die Geräte mit "2.0" nicht einzubinden seien, dies ist aber der RST2 (2 Batterien) und nicht ein RST 2.0 (den gibt es nicht).

Wenn auch der Verpackung nicht hinter dem Typ (hier "Heizkörperthermostat") eine "2.0" steht, dann sind das nicht die HomematicIp Geräte von denen Livisi schreibt.

Quote from PhilippPB

Wie sieht es eigenlich aktuell mit den HKTs aus, die Kesenci verkauft? Da steht neuerdings "nicht über die App programmierbar".

Hast Du mal einen Link? Dann kann ich Dir es vielleicht sagen...

Jetzt da das lokale SmartHome für alle Generationen von Zentralen für alle Verfügbar ist, ist es nur eine Frage der Zeit, bis Livisi die Cloud API für die externen Systeme wie OpenHab und ioBroker abschaltet - habe ich mir jedenfalls gedacht...

Ergo muss ich endlich mal die Baustellen bezüglich meiner OpenHab Installationen (klein im Ferienhaus, groß Zuhause) angehen und das machen, wovor ich mich so lange erfolgreich gedrückt habe: Der Umstieg von 2.4 (kein lokales Binding) auf 3.x (lokales Binding)

Ich habe mich lange davor gedrückt, da ich ein rein Datei basiertes Setup habe und ich wirklich sehr viele, teils komplexe, Regeln verwende. Mit OH 3.x wurden einige Dinge die mich betreffen geändert, bspw. der Format der Zeitangaben, und es war für mich klar, dass ich mich da reinfuchsen muss.

Für diejenigen, die nicht mit Dateien arbeiten, ist das folgende nicht so interessant - für allen anderen ist es hoffentlich eine Hilfe bei ihren Upgrade.

Hier möchte ich auf zwei Änderungen eingehen, die mich in den Regeln besonders betrafen:

• Umstellungen beim triggeringItem
• Die Jodatime (siehe auch DateTime Conversion (openHAB 3.x))

triggeringItem

Diese Umstellungen waren der leichte Teil, da ich hier einfach mit "replace" die entsprechenden Stellen ändern konnte:

• triggeringItem.name wird zu triggeringItemName
• triggeringItem.state wird zu newState (wie bei mir in 98% der Fälle) oder zu previousState

Jodatime

Keine Ahnung, warum das gemacht wurde und was die genauen technischen Details sind - relevant für mich ist nur, wie funktioniert es jetzt?

Nice to know

Eine für mich wichtige Lektion war, dass fast alle Anwendungen der Zeit/Datum in Regeln über den Typ ZonedDateTime erfolgen sollten.

• now, also der übliche Aufruf um eine Zeit/Datum zu bekommen ist jetzt vom Typ ZonedDateTime
• Alternative zu now ist auch ZonedDateTime.now()
• Des weiteren gibt es noch das LocalDateTime, welches u.a. über die Funktion now.toLocalDateTime() kreiert werden kann
• Items vom Typ DateTime speichern scheinbar als LocalDateTime - hier muss also beim Lesen und Schreiben auf eine Konvertierung geachtet werden.
• Die Umwandlung von ZonedDateTime in LocalDateTime erfolgt bspw. über now.toLocalDateTime()
• Die Umwandlung von LocalDateTime in ZonedDateTime erfolgt bspw. über varName.getZonedDateTime()

Lesen und Schreiben von/in Items

• Lesen: var sunrise = (SunSunrise.state as DateTimeType).getZonedDateTime()
• Schreiben: ShellyPumpStarted.sendCommand(pumpStarted.toLocalDateTime().toString)

Rechnen mit Zeiten/Datum

Häufig musst Du in Regeln bestimmte Zeitpunkte ausrechnen, oder Zeiten addieren/subtrahieren:

• Heute Mittag (heute 12:30): var nextNoon = now.with(LocalTime.MIDNIGHT).plusHours(12).plusMinutes(30)
• 5 später: var in5min = now.plusMinutes(5)
• 5min vor Mitternacht: var fiveMinBeforeMidnight = now.addDays(1).with(LocalTime.MIDNIGHT).minusMinutes(5)

Vergleich

Manchmal musst Du herausfinden, ob eine Zeit vor oder nach einem anderen Zeitpunkt liegt:

• Jetzt ist vor "Heute Mittag": now.isAfter(nextNoon)
• Jetzt ist nach "Heute Mittag": now.isBefore(nextNoon)

Formatierte Ausgabe der Zeit/Datum

Früher habe ich dies einfach mit toString gemacht, aber das liefert heute Fehlermeldungen. So geht es:

• Am Anfang der Regeldatei folgenden Import durchführen: import java.time.format.DateTimeFormatter
• Dann kannst Du Variablen vom Typ ZonedDateTime wie folgt formatieren: nextNoon.format(DateTimeFormatter.ofPattern("HH:mm")

Timer

Timer sind manchmal kompliziert, aber folgende einfache Regeln helfen mir ungemein:

• createTimer und reschedule wollen den Datentyp ZonedDateTime haben
• Um einen Timer in verschiedenen Regeln innerhalb einer Datei nutzen zu können, musst Du im am Dateianfang, unter den Importen deklarieren: var Timer myTimer = null
• Prüfen, ob ein Timer aktiv ist: if (myTimer !== null) {...}
• Prüfen, ob ein Timer noch läuft: if (myTimer !== null && !myTimer.hasTerminated()) {...}
• Timer starten: myTimer = createTimer(now.plusMinutes(5), [ | //Do something... ])
• Timer neu starten: myTimer.reschedule(now.plusMinutes(5))
• Timer abbrechen: myTimer?.cancel() und in neuer Zeile myTimer = null

Lektion

Eigentlich ist die Umstellung gar nicht soooo kompliziert, wenn man weiß, was wie geändert werden muss - das herauszufinden hat mich allerdings einige Zeit gekostet.

...so, das war es fürs erste. Ich habe hoffentlich keine groben Fehler eingebaut und vielleicht hilft es jemanden

Weitere Lektionen folgen bestimmt...

Hallo Zusammen,

ich habe jetzt nach der Anleitung von msagner (SHCA Antennentuning.pdf) die Antenne meiner Zentrale 2.0 getuned. Hat gut geklappt und danke nochmal für die tolle Anleitung.

Heute morgen wurde allerdings ein WRT in einem Brunnenschacht, der bisher problemlos meldete, als nicht erreichbar gemeldet. Da alle meine kritischen Geräte mehr oder weniger auf einer Nord-Süd-Achse rund ums Haus liegen (längliches Gründstück), frage ich mich nun, ob ich den SHC in eine bestimmte Richtung drehen sollte um ein optimales Ergebnis zu erzielen.

Variante 1 - quer zur Spriale (SHC steht natürlich nicht hochkant, sondern waagrecht):

Variante 2 - längst zur Spirale (SHC steht natürlich nicht hochkant, sondern waagrecht):

Gibt es bei dieser spiralförmigen Antenne eine optimale Empfangsrichtung? Ist die Abstrahlung quer zur Spirale besser?

Quote from Ralph

Es könnte sein, dass dies ein Reichweitenproblem ist.

Ist es bei mir definitiv - ich werde mal deinen Tipp und auch mal das Antennentuning versuchen.

Danke

Ich habe in meinen Ferienhaus ab und an das Problem, dass die WDS nicht immer den Status korrekt an die Zentrale melden und dadurch einige OpenHab-Regeln im Ferienhaus nicht richtig laufen.

Wenn ich ja weiß, dass die Türen alle verschlossen sind, dann könnte ich das Problem ja lösen, indem ich den Status der Tür manuell setze.

Ja, in LIVISI geht das nicht, aber Gott sei Dank ist dies in OpenHab möglich:

rule "Close All Doors" 
when
    Item CloseDoors changed to ON
then
    if (DoorEntrace.state != CLOSED) DoorEntrace.sendCommand(CLOSED)
    if (DoorBasement.state != CLOSED) DoorBasement.sendCommand(CLOSED)
    if (DoorGuesthouse.state != CLOSED) DoorGuesthouse.sendCommand(CLOSED)
    if (DoorWoodsheed.state != CLOSED) DoorWoodsheed.sendCommand(CLOSED)
    if (DoorToolsheed.state != CLOSED) DoorToolsheed.sendCommand(CLOSED)
    
    CloseDoors.sendCommand(OFF)
end

Zur Erklärung: Ich habe den Switch CloseDoors angelegt, mit welchem ich den Status der WDS in OpenHab (LIVISI ist davon nicht betroffen) auf "Geschlossen" setze. Nachdem die Regel durchgelaufen ist, wird der Switch wieder auf OFF gesetzt.

Sobald von LIVISI ein neuer, anderer Status für einen WDS gemeldet wird, wird das in OpenHab natürlich wieder aktualisiert - die WDS senden aber zum Glück nur wenn sie eine Änderung feststellen

Du musst eventuell die Gruppe ioBroker User erwähnen - dann werden die vielleicht leichter Aufmerksam auf den Beitrag.

Ansonsten kann es durchaus auch mal ein paar Tage brauchen, wenn das Thema komplexer ist - oder es gibt vielleicht nur wenige Nutzer von PC Solar in ioBroker?

Quote from Moehrchen

Bringt mir OPENHAB oder IOBROKER Irgend ein Vorteil?

Man muss schon sagen: die Einarbeitung kostet Zeit und auch hinterher wirst Du angesichts der vielen Möglichkeiten immer mehr und komplexer automatisieren wollen.

Falls Du dich selbst gut stoppen kannst und aufhörst bevor Du Regeln für die Katzenklos oder zur Überwachung des Kühlschranks erstellst, wird dir das OpenSource System aber viel Mehrwert bringen.

Quote from SGK1

Den Download für Zentralen die noch auf Innogy \ RWE Server zugreifen wollen.

Ahhhh

Das wäre in der Tat nicht schlecht. Ich vermute aber mal, dass dies generell noch gemacht wird, da ja irgendwann auch das Update aufs lokale SH ohne Livisi Server möglich sein soll.

Das habe ich verstanden - ich meinte seine Aussage "Fehlt nur noch der Download zum OFFLINE Update. "

Quote from SGK1

Fehlt nur noch der Download zum OFFLINE Update.

Was meinst Du damit?

Im Entwicklerbereich gab es mal eine Info zum VRCC (das ist ein virtuelles "Gerät" für alle Heizungsgeräte eines Raumes) welche vielleicht auch interessant für alle ist:

Vielleicht wissen es viele noch nicht, aber LIVISI SmartHome spannt immer ein virtuelles Raumklimagerät, den VRCC (Virtual Room Climate Control), über alle Klimageräte auf, die einem Raum zugeordnet sind.

Welche Geräte sind im VRCC berücksichtigt?

• RST*
• WRT: Sobald ein WRT im Raum vorhanden ist, gilt der zuletzt eingebundene WRT als Master für den Raum.
• BT-RST
• (FSC8)
• (WDS)

Welche Eigenschaften hat der VRCC?

• Ist-Temperatur: Temperatur des Masters. Sonst Durchschnittstemperatur aller Sensoren des Raums.
• Luftfeuchtigkeit: Luftfeuchtigkeit des Masters. Sonst Durchschnittsluftfeuchtigkeit aller Sensoren des Raums
• Zieltemperatur:
  • Kann direkt für den VRCC gesetzt werden (dann übernehmen alle Geräte die neue Zieltemperatur)
  • Wird über Gerät gesetzt (dann übernehmen die übrigen Geräte und der VRCC die neue Zieltemperatur)

Worum kümmert sich der VRCC sonst so

• FSC8: Steuerung der Ventile - Notfallmodus für den Fall, dass Sensoren im Raum ausfallen
• Window-reduction (Szenario): Sobald ein Fenster im Raum geöffnet ist, setzt der VRCC alle Aktoren in den WR Modus
• Auto/manual Modus aller Aktoren einheitlich steuern (wird per Master gesetzt)
• Zeitgesteuerte Raumtemperatur (Szenario)