openHAB Influx przestał przesyłać dane

Potrzebujesz podać użytkownika/hasło.

@ldywicki 

Użytkownik podany do bazy nie ma hasła, token podany.

Dodane przez: @szpila86

↑

InfluxDB configuration isn't valid. Addon won't work: No credentials

W konfiguracji brakuje danych dostępowych. Jeśli masz influxdb 2 to dodaj do konfiguracji:

version=v2
token=....

Na jakiej wersji OH obecnie jesteś?

Było dodane.

PrZypominam że wszystko działało kilka miesięcy i nagle przestało.

Wersja 3.5

Obecnie testuje dockera 4.0.1 czy coś w podobnie i influx z automatu wstał tylko wyskakują jakieś błędy czasem z zapisem stanu niektórych komponentów ale dopiero w weekend będę w domu

Możesz spróbować sprawdzić przez ssh co widzi system z pliku konfiguracyjnego:

config:edit org.openhab.influxdb
config:property-list
config:cancel

Pierwsze polecenie wchodzi w tryb edycji konfiguracji, z którego wychodzisz ostatnim poleceniem. Komenda `property-list` powinna wypisać wszystkie ustawienia, które są później wykorzystywane przez dodatek do uruchomienia integracji.

Piszę o tym, ponieważ czasami przy edycji plików system potrafi "zatrzymać" wersję pośrednią, którą można odświeżyć tylko usuwając bufory które siedzą w systemie plików.

@ldywicki 

Ciekawe

config:property-list                                                                                                        
   db = OH3
   password = POPRAWNE
   retentionPolicy = openhabdb
   token = POPRAWNY
   url =  http://192.168.xx.xx:49153 
   version = V2

Co ciekawe znów przestało zapisywać dane. Nie wiem czy nie pora influx'a reinstalować i próbować odzyskać dane z bazy

Kod w OH 3.4 oraz 4.0 ma tę samą logikę walidacji parametrów. Błąd, który miałeś w pierwszym poście wynikał z tego, że w konfiguracji nie było parametrów dostępowych (user+password lub token). Logikę tą możesz potwierdzić tutaj: https://github.com/openhab/openhab-addons/blob/4.0.x/bundles/org.openhab.persistence.influxdb/src/main/java/org/openhab/persistence/influxdb/internal/InfluxDBConfiguration.java#L80L100

Komunikat "Cannot load configuration, persistence service wont work" pochodzi z wersji < 4.0. Z komunikatów, które wkleiłeś wynika że w konfiguracji nie było zapisanych uprawnień, ponieważ w drugiej linii są wypisane wszystkie parametry, które były sprawdzone.

@ldywicki 

tylko ze wszystkie pliki, a nawet foldery conf, addon, userdata zostały skopiowane bezpośrednio z wer 3 do 4 wiec wynika z tego że ten sam plik konfiguracyjny w różnych wersjach HO powoduje różne błędy?

Błąd wynika z kopiowania/modyfikowania plików. Zdarza się, że wewnętrzny mechanizm który odczytuje plik i go później przenosi do "cache" się zacina i później nie widzi zmian w plikach które się zmieniają i korzysta z wersji wcześniejszej. Sposobem na potwierdzenie jest porównanie tego, co masz w pliku z tym co wyświetla config:property-list.

Problem z tym jest od bardzo dawna, wydaje mi się że sam pierwszy raz na to trafiłem w OH 2.4. Nie jest to wina samego OH a komponentu/biblioteki która siedzi pod spodem. Próbowałem to kiedyś rozgryźć ale bez powodzenia.

@ldywicki 

Zobaczymy jak to będzie dalej na OH 4.0.3 na chwile obecną przechodzi o dziwo bez większych problemów (nie ma co zapeszać bo nie jedna osoba narzekała na przejście).

czy zapis taki ma sens w OH4 bo u mnie jakoś  go nie akceptuje i muszę z UI dodawać ale i to jakby przestawał zwracać uwagę i nie aktualizuje mimo że dany item jest dodany

influxdb.persist

Strategies {
  default = everyUpdate
}

Items {
  * : strategy = everyUpdate
}

Cześć,

To co masz zapisane w sumie jest redundantne, bo domyślna strategia jest `everyUpdate`, więc `*=everyUpdate` nic nie zmienia. Nie mniej ten obszar w 4.0 mocno się zmienił i konfigurację zapisów do bazy można przeprowadzić przez UI. Kojarzę że był błąd bodajże z JDBC, że część ustawień była ignorowana. Musiałbym poszperać za tym który element zawinił, wiem jednak że konfiguracja przez `.persist` jest dalej wspierana w tej samej składni co wcześniej.

@ldywicki 

Jest jakiś sposób podejrzenia tego co OH myśli że ma na liście do zapisu?

Sposób nieoficjalny jest. Miałem podobny dylemat w 3.0 gdzie chciałem mieć lepszą kontrolę nad tym, które itemy nie powinny być zapisywane. Napisałem własną komendę która to wyświetla: https://github.com/ConnectorIO/connectorio-addons/blob/master/bundles/org.connectorio.addons.persistence.shell/src/main/java/org/connectorio/addons/persistence/shell/internal/PersistenceStrategyCommand.java#L73

Zrobiłem ostatnio port do 4.0.x, ale jeszcze go nie przetestowałem w pełni. Pracuję nad wersją do udostępnienia która będzie dostępna do instalacji przez wrzucenie jar do katalogu addons/.

Komenda wygląda tak:

karaf@local()> co7io-persistence-strategy 
service  'jdbc'
  alias 'restore-states'
  - includes:
    * (all items)
  - strategies:
    PersistenceStrategy [name=restoreOnStartup]
  - excludes:
  alias 'store-changes'
  - includes:
    * (all items)
  - strategies:
    PersistenceStrategy [name=everyChange]
  - excludes:
    HasTag [Computed]
    HasName [.*?_(Minutely|Quaterly|Hourly|Daily|Monthly|Yearly)$]
    HasName [.*?_COP_(Minutely|Quaterly|Hourly|Daily|Monthly|Yearly)$]
    HasName [.*?_(Minutely|Quaterly|Hourly|Daily|Monthly|Yearly)_COP$]
  - defaults:
  - strategies:

W wyniku jest kilka rzeczy, które wynikają ze zmian, które dorzucałem do tej instalacji OH, także wynik dla Ciebie będzie nieco inny.

@szpila86

Spróbuj proszę z: https://repository.connectorio.cloud/repository/co7io-public-snapshots/org/connectorio/addons/org.connectorio.addons.persistence.shell/4.0.0-SNAPSHOT/org.connectorio.addons.persistence.shell-4.0.0-20231011.223528-1.jar

albo kopiujesz ręcznie do katalogu addons albo przez konsolę `install https://….`

@ldywicki 

Wrzucone do addons

OH4 zrestartowane

Dodane przez: @szpila86

↑

@ldywicki 

Wrzucone do addons

OH4 zrestartowane

Dopiero teraz zauważyłem że nie wkleiło mi kodu

openhab> co7io-persistence-strategy                                 
service  'influxdb'
  alias 'null'
  - includes:
    Dzienne_kWh (item)
    Hz (item)
    kWh_Parter (item)
    kWh_Pracownia (item)
    mBierna (item)
    mCzynna (item)
    mCzynnaL1 (item)
    mCzynnaL2 (item)
    mCzynnaL3 (item)
    Miesieczne_kWh (item)
    MocBierna (item)
    MocCalkowita (item)
    mPozorna (item)
    mWspolczynnik (item)
    mWspolczynnikL1 (item)
    mWspolczynnikL2 (item)
    mWspolczynnikL3 (item)
    NapiecieL1 (item)
    NapiecieL2 (item)
    NapiecieL3 (item)
    pracownia_dzienne_kWh (item)
    PradL1 (item)
    PradL2 (item)
    PradL3 (item)
  - strategies:
    PersistenceStrategy [name=everyChange]
  - excludes:
  - defaults:
  PersistenceStrategy [name=everyChange]
  PersistenceStrategy [name=everyUpdate]
  PersistenceStrategy [name=restoreOnStartup]
  - strategies:
  PersistenceCronStrategy [PersistenceCronStrategy [name=everyMinute], cronExpression=0 * * ? * *]
  PersistenceCronStrategy [PersistenceCronStrategy [name=everyHour], cronExpression=0 0 * * * ?]
  PersistenceCronStrategy [PersistenceCronStrategy [name=everyDay], cronExpression=0 0 0 * * ?]
openhab>                                    

Wracam do tematu po dłuższej przerwie - ogólnie `everyChange` i `everyUpdate` nakładają się. Jeśli masz `everyUpdate` to każdy stan zgłoszony przez binding jest zapisywany do bazy, dlatego też `everyUpdate` nic tu nie zmieni. W drugą stronę ta zależność nie jest już spełniona, ponieważ aby stan był zapisany w bazie stan itema musi ulec zmianie. Dla przykładu jeżeli masz licznik odpytywany cyklicznie co 1s to everyUpdate zapisze każdą próbkę powodując że będziesz miał dość dużo danych.

Pozdrawiam,
Łukasz

@ldywicki problem w tym iż danych nie ma, a nie że ich jest nad stan.

Dla przykładu wykres napięć L1 L2 L3 z 30 dni bo z 7 nie ma danych...

W teorii powinno być ileś rekordów na godzinę przez te 30dni a jest jak jest

a po przejściu na konfiguracje tekstowa w pliku mam

co7io-persistence-strategy
service  'influxdb'
  alias 'null'
  - includes:
    * (all items)
  - strategies:
    PersistenceCronStrategy [PersistenceCronStrategy [name=everyChange], cronExpression=everyChange]
    PersistenceStrategy [name=null]
  - excludes:
  - defaults:
  - strategies:
  PersistenceCronStrategy [PersistenceCronStrategy [name=everyChange], cronExpression=everyChange]

I zobaczymy czy coś to da pozytywnego po 15 min działania uruchomiłem ponownie OH i znów przestało dziać

openhab> co7io-persistence-strategy
service  'influxdb'
  - defaults:
  - strategies:
openhab>

persist

Strategies {
    everyChange: "everyChange",
    restoreOnStartup: "restoreOnStartup"
}

Items {
    * : strategy = everyChange, everyMinute, restoreOnStartup
}

Cześć, możesz włączyć debug dla org.openhab.persistence.influxdb i sprawdzić czy rzeczywiście zapisy idą do bazy?