Member of Grupp und last seen /Last update

[udo1toni]

Also, eine MySQL Datenbank zu konsolidieren, läuft gewöhnlich über einen SQL Dump, DB Drop und anschließend Import. oft geht das wegen der Dateigrößen schief. Was aber fast immer funktioniert ist, das Prozedere tabellenweise durchzuführen.
Testdaten wird man mit passenden Löschabfragen los (im Fall der openHAB Daten musst Du den entsprechenden Zeitraum kennen, danach filtern und alle gefundenen Datensätze löschen lassen.)
Doppelte Items: Ich gehe davon aus, dass es sich um Items handelt, die Du zu irgendeinem Zeitpunkt umbenannt hast? Oder sind tatsächlich mehrere Tabellen für das selbe (!) Item vorhanden? In letzterem Fall kannst Du die betroffenen Tabellen mit kleinerer Itemnummer mit einer Anfügeabfrage an die Tabelle mit der größten Itemnummer anfügen (und unbedingt in der Items-Tabelle die betreffenden Einträge löschen, bis auf das mit der höchsten Itemnummer). Danach kannst Du die überflüssigen Tabellen droppen. Bei Items, deren Name geändert wurde, gilt sinngemäß das gleiche, nur sind hier unterschiedliche Namen in der items Tabelle zu berücksichtigen.

Je nachdem, um welches Synology Modell es sich handelt, kann es tatsächlich etwas schwachbrüstig für MySQL sein, Datenbanken brauchen vor allem RAM, um möglichst alle Tabellen direkt lesen zu können. Auf moderner Hardware kann ein nvme-Cache Linderung verschaffen, aber RAM ist das eigentliche Mittel für Geschwindigkeit.

Für das lastUpdate Problem reicht aber tatsächlich die MapDB locker aus, es geht dabei ja nur um den letzten Zugriff und nicht um beliebige historische Daten.

[boing86]

Doppelte Items: Ich gehe davon aus, dass es sich um Items handelt, die Du zu irgendeinem Zeitpunkt umbenannt hast? Oder sind tatsächlich mehrere Tabellen für das selbe (!) Item vorhanden?

Es gab leider doppelte einträge mit dem gleichen Item Name. Ich habe die Tabelle mit weniger Daten gelöscht, und in items entfernt.
Auch habe ich Bewegungsmelder Daten gelöscht, die hatte ich eigentlich nur temporär oder für einige Tage speichern wollen.

Je nachdem, um welches Synology Modell es sich handelt, kann es tatsächlich etwas schwachbrüstig für MySQL sein, Datenbanken brauchen vor allem RAM, um möglichst alle Tabellen direkt lesen zu können. Auf moderner Hardware kann ein nvme-Cache Linderung verschaffen, aber RAM ist das eigentliche Mittel für Geschwindigkeit.

Meine Synology ist jetzt beim DSM 7.2 update nicht mehr Supportet.(1513+)

Für das lastUpdate Problem reicht aber tatsächlich die MapDB locker aus, es geht dabei ja nur um den letzten Zugriff und nicht um beliebige historische Daten.

Gibt es irgendwie eine Möglichkeit nachzuschauen was da gespeichert ist? Ich habe bemerkt das es keinen log Eintrag erstellt oder eine Benachrichtigung sendet. Die Meldung kommt bisher nur nach einem Booten wenn einige Werte noch keinen Wert haben.
zb.-> OPPLE_Schalter_24_lastup seit null ohne Update!

Screenshot 2023-11-06 211454.png

Bei den Sensoren habe ich das selbe Problem da sollten eigentlich zwei Meldungen kommen.

Screenshot 2023-11-06 213113_2.png

Code: Alles auswählen

val telegramAction = getActions("telegram","telegram:telegramBot:Telegram_Bot")

rule "Zeitvergleich Schalter"
when 
    Item TEST_schalter changed or// nur zum debugen  
    Time cron "0 0 18 * * ?" //um 18:00
then

    LastUpdateHB_schalter.members.filter[i|!i.updatedSince(now.minusDays(2),"mapdb")].forEach[j |
        logWarn("timecheck","Item {} seit {} ohne Update!",j.name, j.lastUpdate)
        telegramAction.sendTelegram("***************************************\n" 
                        +"OH4 Timecheck Schalter\n"+j.name+" seit " +j.lastUpdate+" ohne Update!"
                        +"\n***************************************" 
               )
    ]

end 


rule "Zeitvergleich Sensor"
when 
     Item TEST_schalter changed or// nur zum debugen  
    Time cron "0 0 18 * * ?" // um 18:00
then

    LastUpdateHB_sensor.members.filter[i|!i.updatedSince(now.minusDays(2),"mapdb")].forEach[j |
        logWarn("timecheck","Item {} seit {} ohne Update!",j.name, j.lastUpdate)
        telegramAction.sendTelegram("***************************************\n" 
                        +"OH4 Timecheck Sensor\n"+j.name+" seit " +j.lastUpdate+" ohne Update!"
                        +"\n***************************************" 
               )
    ]
end  

Die mapdb.persist sieht so aus.

Code: Alles auswählen

Strategies {
everyMinute : "0 * * * * ?"
everyHour : "0 0 * * * ?"
everyDay  : "0 0 0 * * ?"

default = everyChange

}
Items {
    LastUpdateHB_schalter*       : strategy = everyChange,restoreOnStartup
    LastUpdateHB_sensor*         : strategy = everyChange,restoreOnStartup
    
}

[boing86]

Hallo

Irgendwie stehe ich auf dem schlauch. Weil die Benachrichtigungen gehen nicht/nicht richtig.

Heute hatte ich einmal versucht herauszufinden was in der mapdb steht.

Bei der rule habe ich das ! entfernt und erwarte das jetzt immer der zu letztgespeicherte Timestamp zurück kommt.
Aber es kommt null zurück.

Wenn ich die Logs richtig interpretiere werden die werte gespeichert und de gelesen aber nicht ausgegeben.
Ich habe auch blind drauflos andere "variablen" versucht anstellt j.lastUpdate aber hatte auch kein Erfolg.

Ich vermute diese Variante geht nicht mehr sofern mein Englisch nicht allzu schlecht ist.
https://community.openhab.org/t/oh3-map ... e/112984/4

Code: Alles auswählen

rule "Zeitvergleich Schalter"
when 
	Item TEST_schalter changed or// nur zum debugen  
    Time cron "0 0 18 * * ?" //um 18:00
then
    LastUpdateHB_schalter.members.filter[i|i.updatedSince(now.minusDays(2),"mapdb")].forEach[j |
        logWarn("timecheck","Item {} seit {} ohne Update!",j.name, j.lastUpdate)
        telegramAction.sendTelegram("***************************************\n" 
                        +"OH4 Timecheck Schalter\n"+j.name+" seit " +j.lastUpdate+" ohne Update!"
                        +"\n***************************************" 
               )
    ]

im openhablog sieht es dann so aus:

Code: Alles auswählen

2023-11-29 20:07:10.046 [DEBUG] [pdb.internal.MapDbPersistenceService] - store called for OPPLE_Schalter_23_lastup
2023-11-29 20:07:10.049 [INFO ] [l.script.Button OPPLE_Schalter_23 OL] - Einmal gedrukt
2023-11-29 20:07:10.069 [DEBUG] [pdb.internal.MapDbPersistenceService] - Stored 'OPPLE_Schalter_23_lastup' with state '2023-11-29T20:07:10.043+0100' as '{"name":"OPPLE_Schalter_23_lastup","state":"org.openhab.core.library.types.DateTimeType@@@2023-11-29T20:07:10.043+0100","timestamp":"Nov 29, 2023, 8:07:10 PM"}' in MapDB database

2023-11-29 20:07:20.205 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'TEST_schalter' changed from OFF to ON


2023-11-29 20:07:20.844 [DEBUG] [pdb.internal.MapDbPersistenceService] - Deserialized 'OPPLE_Schalter_23_lastup' with state '2023-11-29T20:07:10.043+0100' from '{"name":"OPPLE_Schalter_23_lastup","state":"org.openhab.core.library.types.DateTimeType@@@2023-11-29T20:07:10.043+0100","timestamp":"Nov 29, 2023, 8:07:10 PM"}'
2023-11-29 20:07:20.844 [WARN ] [.openhab.core.model.script.timecheck] - Item OPPLE_Schalter_23_lastup seit null ohne Update!

[udo1toni]

Ich vermute diese Variante geht nicht

Nein, es besteht ein fundamentaler Unterschied zwischen changedSince und updatedSince.
Für changedSince braucht es einen alten Status oder anders ausgedrückt eine Historie. Für updatedSince ist lediglich interessant, wann das Item zuletzt ein Update erhalten hat, das sollte auch mit mapDB einwandfrei funktionieren.
Genauso der Zeitstempel, der über lastUpdate ausgegeben werden sollte.
Alternativ könnte man noch timestamp probieren, aber dazu müsste das Item vermutlich eines vom Typ HistoricItem sei, ich denke nicht, dass das bei mapDB der Fall ist.

Als Workaround kannst Du DateTime Items für jeden der fraglichen Channel anlegen und diese jeweils über das Profile system:timestamp-update an den Channel andocken. Allerdings musst Du dann die Zeitstempel auswerten, was zwar geht, aber auch kompliziert ist (wegen der notwendigen Typwandlung von DateTimeType nach DateTime).

[boing86]

Ich hatte in der zwischen Zeit diverse Sachen ausprobiert leider Ohne Erfolg.
Heute hat es geklappt, danke ein wenig Hilfe von KI (Msty).

Code: Alles auswählen

rule "Zeitvergleich Schalter"
when
	Item TEST_schalter changed or// nur zum debugen  
    Time cron "0 0 18 * * ?" // um 18:00
then
    val nowMinusTwoDays = now.minusDays(2)

    LastUpdateHB_schalter.members.forEach[item |
        if (item.state instanceof DateTimeType) {
            val itemDateTime = (item.state as DateTimeType).getZonedDateTime()
            if (itemDateTime.isBefore(nowMinusTwoDays)) {
                logInfo("DateTimeCheck", "Item '{}' (Label: '{}') ist älter als zwei Tage: {}", item.name, item.label, item.state.toString)
                telegramAction.sendTelegram("***************************************\n" 
                    +"OH4 Timecheck Sensor\n"+item.label+" "+item.name+" ohne Update seit\n" +item.state.format("%1$tA, %1$tY-%1$tm-%1$td, %1$tH:%1$tM")+""
                    +"\n***************************************" 
               )
            }
        } else {
            logWarn("DateTimeCheck", "Item '{}' (Label: '{}') hat keinen gültigen DateTime-Wert: {}", item.name, item.label, item.state.toString)
                telegramAction.sendTelegram("***************************************\n" 
                +"OH4 Timecheck Sensor\n"+item.name+" hat keinen gültigen DateTime-Wert: " +item.state.toString+" !"
                +"\n***************************************" 
               )
        }
    ]
end

[udo1toni]

Nö.
Diese Rule prüfst lediglich, ob ein Item, welches als Status DateTimeType liefert, einen Status hat, der (als DateTimeType interpretiert) einen Zeitstempel älter als zwei Tage liefert.
Abgesehen davon ist der Code spätestens mit openHAB4.3 syntaktisch fehlerhaft.
Du müsstest dann schon noch zusätzlich die Zeitstempel in eigene Items schreiben, das ist völlig am Problem vorbei. Natürlich kannst Du extra DateTime Items anlegen, welche für jeden zu überwachenden Channel über das Profile lastUpdate automatisch einen Zeitstempel zugewiesen bekommen,aber das war ja nicht die Frage.