openhabforum.de

Pi4b, Openahbian 2.5.12
Ich möchte das upgrade auf openhabian 3 (gerade 3.2 stable gekommen) endlich machen.
Auf meinem alten Pi3b habe ich nun mal OH3.2 installiert und OhJe was ist das denn....... das ist doch ganz anders....

Ich habe mich nun erst mal etwas mit Tutorial und Documentation beschäftigt, dabei stellen sich mir nun viiiieeeele Fragen.
Vielleicht könnt ihr mir hier etwas weiterhelfen, ich versuche das mal auf die wesentlichen Dinge zu verdichten

1. Ich habe OH 2.5.12 auf einer 1TB SSD laufen. Damals hatte ich die Partitions so angepasst, daß ich eine zusätzliche
separate Partition (3.Partition ca. 800GB) als Samba shared drive verwende (also ein primitives NAS).
Das bringt mich nun zu meinem ersten Problem, wie mache ich das Upgrade?
a. Am Liebsten würde ich ja die integrierte Upgrade Funktion verwenden, denn dann passiert meinen Partitions ja nichts.
Aber wenn ich mir die MainUI anschaue frage ich mich wie sieht das denn nach dem Upgrade aus, legt der selbständig Räume an?
Kann ich das nachträglich auch alles ändern, denn das Konzept ist ja ganz anders als im OH2?
b. Kann ich evtl. auf meinem Pi3b die komplette Konstellation aufbauen, mit dem Backup von 2.5 und dann den Inhalt
(also boot und root) mit DD auf meine SSD bügeln und der PI4 läuft damit oder ist das inkompatibel Pi3 und Pi4?
c. Was ist denn das für ein Kä.. mit UI oder Text, Was muß ich denn wo selektieren um dies oder das zu verwenden?
Ich finde kein Setting dafür. Und wenn ich nun das intergrierte Upgrade verwende, wo landen denn meine items, things
und rules? Das ist nicht gut dokumentiert würde ich sagen!

2. Wenn ich nun evtl. zum Testen auf dem PI3b in OH3 das Backup vom OH2 lade, was passiert denn dann?
Die eigentliche Installation läuft ja noch. Dann wären alle items, rules ... alle nochmal eingebunden, Chaos oder geht das?

3. Wenn das Upgrade direkt auf dem PI4 in die Hose geht, oder vieles nicht funktioniert, kann ich dann auch nochmal zurück?

4. Hat jemand einen kleinen Überblick, was ich in meinen rules anpassen muß?
Und wo pass ich das denn an, mach ich da weiterhin putty und nano, oder wie?

Du bist ja lustig... openHAB3 ist schon seit über einem Jahr stable draußen, und Du hast davon noch nichts mitbekommen?

Vorweg: Was hast Du nun tatsächlich laufen, Deine Angaben sind teils widersprüchlich (bzw. ich steige nicht durch)... Pi4 oder Pi3?

Zu 1.: Die drängendste Frage ist, welchen Stand Dein OS hat. Seit ~ Juni ist debian bullseye die stable Version, Raspberry Pi OS für den Pi4 basiert auf bullseye, weil der Pi4 mit buster nicht läuft (der Kernel passt nicht).
Weiter wäre zu klären, wie Dein System bootet. Tut es das direkt von SSD? Wie hast Du das damals eingerichtet?
1.a: Ja, ein Upgrade sollte eigentlich normal funktionieren. Aber vor einem Sprung der Major Version (eigentlich auch bei kleinen Updates) sollte man seinen Datenbestand sichern. Das bezieht sich ausdrücklich auch auf Daten auf "unbeteiligten" Partitionen. Das ist einer der Gründe, warum eine große SSD eher suboptimal ist.
Was die Räume betrifft (wäre besser gewesen, Du hättest Deine Fragen etwas strukturiert...

) so macht openHAB nichts selbst. Das gesamte Thema lässt sich unter dem Begriff semantic Model zusammenfassen. Man kann Items über das semantic Model organisieren. Man muss das nicht tun, kann es aber jederzeit machen und auch ändern. Das Konzept des semantic Model baut auf bestehenden Strukturen auf und es gab auch unter openHAB1(!) schon die Möglichkeit, seine Items nach dem semantic Model anzulegen. Nur gab es den Begriff dafür nicht und man hatte dadurch nur sehr begrenzt Vorteile.
1.b: Das Hauptproblem ist das OS. Der Pi3 verwendet andere Hardware als der Pi4. Mit einem aktuellen Image (Raspberry Pi OS lite oder openHABian) kannst Du Glück haben, aber das ist nicht garantiert. Ich würde eher davon abraten.
1.c:? Das funktioniert exakt so, wie auch schon unter openHAB2. Du kannst unter /etc/openhab/ in der gewohnten Ordnerstruktur die Konfiguration über Textdateien erledigen oder die Main UI verwenden. Du kannst beide Verfahren mischen, auch wenn davon eher abzuraten ist. Es ist exakt wie schon bei openHAB2 so, dass Daten, die in der UI angelegt werden, nicht in den Textdateien auftauchen. Umgekehrt taucht zwar die Konfiguration der Textdateien in der UI auf, ist dort aber nur lesbar (die Einträge sind dann mit einem Schloss markiert und lassen sich über die UI nicht speichern).
Dokumentiert ist das ganz hervorragend.

2.: Du hast zwei getrennte openHAB Systeme auf zwei getrennten Rechnern. Erst mal haben die beiden nichts miteinander zu tun. Je nach verwendeten Bindings und Hardware kann es sogar sein, dass beide Systeme parallel auf alles zugreifen können. Wenn openHAB korrekt konfiguriert ist (das heißt, jeder Schaltvorgang wird mit einem passenden Status vom Bus beantwortet), sollten sogar beide Systeme jederzeit korrekt arbeiten, auch nebeneinander. Änderst Du in dem einen System eine Schaltstellung, so wird das auf dem anderen System als Statusänderung wahrgenommen und umgekehrt. Einzig Rules könnten hier problematisch sein, je nach Funktionsweise und Aufgabe der Rule.

3. Wenn Du vorher ein Backup machst, kannst Du das wieder einspielen.

4. Es gibt eigentlich nur zwei Dinge, solange Du die Rules identisch zu openHAB2 nutzt (also über rules Dateien in /etc/openhab/rules/).
Das eine ist eine Änderung, die impliziten Variablen betreffend. in openHAB2 gibt es die implizite Variable triggeringItem, welche ein Objekt darstellt, welches dem triggernden Item der Rule entspricht. Diese implizite Variable steht in openHAB2 immer zur Verfügung, solange die Rule durch ein Item getriggert wurde. Unter openHAB3 steht triggeringItem nur noch zur Verfügung, wenn die Rule durch den Trigger Member of... getriggert wurde. Wurde die Rule hingegen durch Item ... getriggert, so steht die (neue) implizite Variable triggeringItemName zur Verfügung, welche auch nur den Namen des Items als String enthält. (sehr schade, damit sind dann dort keine Konstrukte wie triggeringItem.state möglich)
Der zweite (größere) Punkt ist die Umstellung von Joda Time auf JavaTime. Beide Varianten nutzen now(), aber danach wird es anders. Die Unterschiede sind teilweise klein (z.B. .getHour statt getHourOfDay), teilweise aber auch schwerwiegend, weil eine Funktion so überhaupt nicht oder nur in völlig anderer Form zur Verfügung steht. Mir ist leider keine direkte Gegenüberstellung der beiden Bibliotheken bekannt, was konkrete Funktionen betrifft. Konzepte kann man hier vergleichen: https://blog.joda.org/2014/11/convertin ... atime.html und https://www.it-swarm.com.de/de/java/unt ... 046710409/ macht das in Textform.

Na sei doch nicht so streng mit den Laien bzw. Halb-Laien, ich schieb das OH3 schon die ganze Zeit vor mir her,
weil mir der Änderungsaufwand einfach zu groß erschien. Nun bin ich mit meiner OH2 Installation zufrieden, habe das gerade noch mit ein
paar Reed-Kontakten erweitert, und da denke ich mir ich kann mich der nächsten Challenge OH3 zuwenden, man kann ja nicht ruhig halten

Ich habe meine eigentliche Installation Openhabian 2.5.12 (Buster) auf dem PI4b laufen. Starten tu ich von der 1TB SSD.
Da habe ich damals nach der initialen Installation die Partitions angepasst, die 2.Partition verkleinert (d.h. Openhabian benutzt im Standard
ja nur root und boot) und eine 3.Partition für Daten (samba share) angelegt.
Openhabian 3.2 habe ich gestern mal zur Probe auf einer SD-Card auf meinem alten Pi3b installiert, so drängte sich mir der Gedanke auf,
ob ich da die Installation von 3.2 finalisieren kann, und wenn alles OK ist auf den PI4 umsetzen, aber das ist wegen der Hardware nicht ganz
so einfach bzw. unsinnig.
Wenn ich das Update nun einfach per Openhabian-Config -> Update mache habe ich Bedenken wie das nachher aussieht und das ich mir
damit vielleicht unnötige Probleme einhandele. Die Gefahr eines "Umpartitionieren", wie bei einer Neuinstallation hätte ich da aber nicht, korrekt?
Obwohl ein Neuaufsetzen wahrscheinlich am Besten wäre.
Aber wie krieg ich das denn am Besten hin? Klar, Backup extern sichern, habe ich schon gemacht, aber wie bekomme ich denn nun eine
initiale Openhabian3.2 Installation auf die bestehenden SSD Partitions?
Ich habe das 3.2 ja momentan komplett initial auf dem PI3 am Laufen, kann das irgendwie von dort ...auf den PI4..?
EDIT: Ich könnte doch eine initiale SD-Card mit Openhabian3.2 am PI4 starten, nach dem Starten die SSD dranhängen und von der SD
die beiden Partitions auf die bestehenden SSD Partitions kopieren (DD vom laufenden System auf die gemountete SSD?) Geht das?

Aber was mich ja am Meisten aufhält sind die rules, ich bin da super stark äääh schwach

Ich habe da insbesondere so ein Alarm rule, welches Dir sicher irgendwie bekannt vorkommt, dieses beinhaltet einige Feinheiten,
wie z.B. diese triggering items ....
Das traue ich mir nicht zu, ich hänge es mal an, kannst Du da bitte mal drauf schauen?

Code: Alles auswählen

import java.util.List				
var List<Timer> timers = newArrayList 
var Timer shutoffTimer = null      
var Timer LEDTimer1 = null     
var Timer LEDTimer2 = null      
var Timer SireneTimer1 = null			
var DateTime lastRun = 0								

rule "Rule Datei eingelesen"
when
    System started
then
    lastRun = now.minusMinutes(2)								
end

rule "Bewegung 3 mal in einer Minute"
when
    Member of gBW changed from OFF to ON
then
    if(MailSenden.state == ON) {                                                                
        val mailText = "Bewegungsmelder " + triggeringItem.name + " hat ausgelöst"		
        mailActions.sendMail("xxx@gmail.com","Alarm "+ triggeringItem.name, mailText)													
    }												
    if(TelegramSenden.state == ON) {                                                           
	val telegramAction = getActions("telegram","telegram:telegramBot:xxx")		
        telegramAction.sendTelegram("Bewegungsmelder An  - %s", triggeringItem.name)	
    }												
    if(E_Touch10_2.state == OFF) {                                                             
        logInfo("bw_alarm","Alarmanlage aus, Rule Ende!")					
        return;										
    }												
    if(LEDTimer1 === null) {                                                                    
        gLED.sendCommand(ON)                                                                 	
        LEDTimer1 = createTimer(now.plusSeconds(5), [ |                                         
            gLED.sendCommand(OFF)								
            LEDTimer1 = null									
        ] )										
    }												
    if(SireneTimer1 === null) {                                                                
	LED_BeepMast.sendCommand(ON)    
//	Sirene_Gaeste.sendCommand(ON)                                                       
//	Sirene_Mast.sendCommand(ON)
        SireneTimer1 = createTimer(now.plusSeconds(5), [ |                                 	
	    LED_BeepMast.sendCommand(OFF)
//      Sirene_Gaeste.sendCommand(OFF)								
//	Sirene_Mast.sendCommand(OFF)
            SireneTimer1 = null									
        ] )											
    }												
    if(shutoffTimer !== null) {                                                               
        logInfo("bw_alarm","Alarm schon aktiv, Rule Ende!")					
        return;											
    }												
     if(lastRun.isAfter(now.minusMinutes(2))) {                                       
        logInfo("bw_alarm","letzter Alarm vor weniger als 2 Minuten, Rule Ende!")	
        return;											
    }										
    if(timers.size < 3) {                                                                      
        val t = createTimer(now.plusMinutes(1), [ |						
            timers.remove(0)								
        ] )										
        timers.add(t)										
    }												
    if(timers.size == 3) {                                                            
        if(MailSenden.state == ON) {                                                    
		val mailActions = getActions("mail","mail:smtp:xxx")		
		mailActions.sendMail("xxx@gmail.com","Sirene aktiviert ", "Alarm ON") 
        }											
        if(TelegramSenden.state == ON) {                                                       
		val telegramAction = getActions("telegram","telegram:telegramBot:xxx")	
        telegramAction.sendTelegram("Alarm ON")						
        }										
	LED_BeepMast.sendCommand(ON)		
//      Sirene_Gaeste.sendCommand(ON)								
//      Sirene_Mast.sendCommand(ON)
		
        LEDTimer2 = createTimer(now.plusMillis(10), [ |                                     
            if(gLED.state != ON) {                                                     
                gLED.sendCommand(ON)                                                     
                LEDTimer2.reschedule(now.plusSeconds(5))                                    
            } else {                                                                      
                gLED.sendCommand(OFF)                                                    
                LEDTimer2.reschedule(now.plusSeconds(5))                                      
            }										
        ] )										
        lastRun = now									
        while(timers.size > 0) {								
            timers.get(0).cancel								
            timers.remove(0)									
        }										
        shutoffTimer = createTimer(now.plusSeconds(60), [ |                                    
	    LED_BeepMast.sendCommand(OFF)
//          Sirene_Gaeste.sendCommand(OFF)							
//          Sirene_Mast.sendCommand(OFF)
            logInfo("Alarmrule", "Sirene Ende")							
            LEDTimer2?.cancel                                                                
            LEDTimer2 = null									
            if(gLED.state != OFF)                                                        	
                gLED.sendCommand(OFF)                                                    	
            shutoffTimer = null									
        ] )											
    }												
end

Soweit ich das überblicke, gibt es nur eine einzige Stelle, die geändert werden muss, das ist now.plusMillis(10). Java Time ist auf Nanosekunden ausgerichtet, mit Millisekunden gibt sich Java Time deshalb nicht ab. Du musst also now.plusNanos(10000000) schreiben.

Echt, aber hier sind doch diese triggering items drin, sind die denn schon korrekt so?
Und meine Frage bzgl. DD von einer frischen openhabian 3 Installation, auf die root/Boot partitions der SSD geht das von einem laufenden System?

Wie gesagt... triggeringItem ist durchaus gültig, aber eben nur, wenn die Rule mit einem Member of getriggert wird.

Meine Erfahrung bezüglich klonen eines Systems ist, dass man das besser bei heruntergefahrenem System macht. das heißt, Du brauchst einen Rechner, an dem Du sowohl die SD-Karte in einem Lesegerät als auch die SSD angeschlossen haben kannst. Das kann durchaus auch der Pi selbst sein, aber er sollte nicht von der SD-Karte gebootet sein (sprich: Du brauchst ein zusätzliches SD-Karten-Lesegerät, welches Du über USB anschließen musst).

Ja das mit dem Klonen leuchtet ein denn wenn der Pi läuft ist die Quelle ja nicht geblockt.
Ich habe jetzt eine kleinere SSD mit OH3 aufgesetzt, und werde den Stück für Stück neu aufsetzen.
Zuerst die ganze Hardware/Bindings und dann die rules.
Da wird mir sicher noch ein oder zwei Problemchen...

BTW Frohe Weihnachten

openhabforum.de

Openhabian Upgrade 2.5.12 auf 3.2

Openhabian Upgrade 2.5.12 auf 3.2

Re: Openhabian Upgrade 2.5.12 auf 3.2

Re: Openhabian Upgrade 2.5.12 auf 3.2

Re: Openhabian Upgrade 2.5.12 auf 3.2

Re: Openhabian Upgrade 2.5.12 auf 3.2

Re: Openhabian Upgrade 2.5.12 auf 3.2

Re: Openhabian Upgrade 2.5.12 auf 3.2