Cerbo GX tovarni restart.

[sodar2]

Neprováděl někdo na cerbu GX tovární restart. Začalo se mně kousat cerbo, několikrát za den. Podle návodu to nic nedělá.

Dík.

[pibi]

Zatím nebylo třeba, jediný návod co jsem našel:
https://www.victronenergy.com/media/pg/ ... edure.html

[sodar2]

Podle toho návodu jsem valil a nic.

[Diablo1st]

Skúsil by som upgrade, príp. downgrade firmware. Mne jedna verzia tiež dosť mrzla.
Čo všetko máš v Cerbe napchané? U jednej inštalácie mrzlo Cerbo a po výmene RS485 za originál od Victronu sa mrznutie Cerba dramaticky znížilo.

[sodar2]

downgrade nepomaha, naposled jsem tam neco delal s shelly. Projdu to, ale myslel jsem ze restart do tovarniho bude teda mensi porod.

[Atman]

Podle toho návodu jsem valil a nic.

Nic znamená že to nespadlo do firmware 1.00 alebo že to nepomohlo s mrznutím?

[sodar2]

Asi se jsem našel příčinu problému se zatuháváním cerba.

Projevovalo se to tak, že zatuhl cerbo většinou tak do hodiny, nedalo se do něj dostat, jen po restartu.
Když jsem udělal nějakou změnu v nastavení tak se neuložila a po zatuhnutí a následném restartu nebyla změna uložena a zůstalo tam uložené nastavení ještě před zásekama.

Pravděpodobná příčina, byla instalace „dbus-shelly-1pm-pvinverter“ nějak jsem na to zapomněl a nechal v systému cerba.
Shelly si tam vytvořilo log který postupně sežral veškeré místo na uložišti a tím cerbo začalo být nestabilní. Po smazání jakýchkoli známek po shelly to vypadá že je po problému.

Tovární restart podle návodu na mém cerbu prostě nefungoval, firmware se vůbec nepřehrál. Nevím jestli jsem dělal něco blbě nebo je to nějaká chyba.


Tak snad je po problému.

V panice jsem objednal Cerbo-S GX tak kdyby někdo chtěl prodám za nákupku 4400 Kč. Nerozbalené se zárukou, přišlo před chvilkou.

[glottis]

jo podobnou veci jsem se taky potrapil. V config.ini pro shelly jde nastavit loglevel. Asi tam bylo debug a staci nastavit info.

dalsi vec co me trapila, byla zatez procesoru. Pomohlo zpomalit nacitani dat z shelly

v python zdrojaku je radek ...

Kód: Vybrat vše

    # add _update function 'timer'
    gobject.timeout_add(2000, self._update) # pause 500ms before the next request

a tam jsme si misto 500ms nastavil 2000ms zatez rapidne klesla.

[johny.h]

Zdravím solárníky.
Dostal jsem se pravděpodobně nějakou svojí chybou do stejné situace plné paměti v Rpi 4B.
Nejde mi "current.log" smazat ani dle rad zkušenějšího človíčka z githubu.
root@raspberrypi4:/data/dbus-shelly-3em-smartmeter# du
du: ./current.log: Value too large for defined data type

root@raspberrypi4:/data/dbus-shelly-3em-smartmeter# rm -rf current.log
rm: can't stat 'current.log': Value too large for defined data type

Dokážete prosím poradit, jak ten log vymáznout, pokud možno bez resetu systému, abych vše nedělal znovu?
Rozhodně nejsem znalý v Pythonu, ale nějaké příkazy už si sepisuji
Díky.

[glottis]

zkus

echo "" > /data/dbus-shelly-3em-smartmeter/current.log

nebo

cat /dev/null > /data/dbus-shelly-3em-smartmeter/current.log

[Soban]

Pokud to máš na SD kartě nebude nabořen systém - poškozená karta?

Vytáhnout a smazat soubor v PC.

[johny.h]

zkus

echo "" > /data/dbus-shelly-3em-smartmeter/current.log

nebo

cat /dev/null > /data/dbus-shelly-3em-smartmeter/current.log

Díky za reakci. Nevím co to mělo udělat, ale dle mě výsledek žádný:

root@raspberrypi4:~# echo "" > /data/dbus-shelly-3em-smartmeter/current.log
root@raspberrypi4:~#
root@raspberrypi4:~# cat /dev/null > /data/dbus-shelly-3em-smartmeter/current.log
root@raspberrypi4:~#

[glottis]

Vyprázdnit soubor a zachovat ho. Pokud to nejde a nejde to ani mazat je možné že je opravdu naboreny FS.

[johny.h]

Pokud to máš na SD kartě nebude nabořen systém - poškozená karta?

Vytáhnout a smazat soubor v PC.

Díky za reakci.
Kartu jsem před pár měsíci kontroloval, když jsem problém zjistil, ale má pouze 21.7MB, tedy zobrazeno ve Win průzkumníku.
Musím to zjišťovat v jiném programu?
Pro jistotu přidávám kompletní výpis:

root@raspberrypi4:/data# df
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/root 1065248 1012736 0 100% /
devtmpfs 1930856 4 1930852 0% /dev
tmpfs 1964648 900 1963748 0% /run
tmpfs 1964648 432 1964216 0% /var/volatile
/dev/mmcblk0p1 42180 22334 19846 53% /u-boot
/dev/mmcblk0p4 20792144 20775760 0 100% /data
/dev/sda1 7826432 400 7826032 0% /run/media/sda1
tmpfs 1964648 900 1963748 0% /service

[johny.h]

Vyprázdnit soubor a zachovat ho. Pokud to nejde a nejde to ani mazat je možné že je opravdu naboreny FS.

To jsme včera večer zkoušeli, ale bez úspěchu:

root@raspberrypi4:/data/dbus-shelly-3em-smartmeter# rm -rf current.log
rm: can't stat 'current.log': Value too large for defined data type
root@raspberrypi4:/data/dbus-shelly-3em-smartmeter# ./restart.sh

[Soban]

Ono ty karty moc nevydrží jak se na ně zapisuje.
rpi4 umí běžet a startovat z ssd, tak nějaké pořiď do usb a budeš v klidu.....

[hibiki]

root@raspberrypi4:/data# df
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/root 1065248 1012736 0 100% /
devtmpfs 1930856 4 1930852 0% /dev
tmpfs 1964648 900 1963748 0% /run
tmpfs 1964648 432 1964216 0% /var/volatile
/dev/mmcblk0p1 42180 22334 19846 53% /u-boot
/dev/mmcblk0p4 20792144 20775760 0 100% /data
/dev/sda1 7826432 400 7826032 0% /run/media/sda1
tmpfs 1964648 900 1963748 0% /service

Mas obsazene veskere volne misto

[Soban]

Při 100% zaplnění to musí jít smazat....

[johny.h]

Včera jsme opravdu prováděli nespočet příkazů při pokusech o smazání liogu, ale vždy se log tvářil nepřístupně, jak jsem psal výše. Vše tedy děláno v Putty.
Jestli to tedy musí jít smazat, napiš mi prosím jakým příkazem a až se vrátím po 14.h. domů, hned to otestuju.
Poznáte z toho výpisu, jestli se jedná o microSD nebo Rpi paměť?
SD karta se opravdu tváří jako skoro prázdná.
Všem zatím moooc děkuji za ochotu.

[sodar2]

Ja se připojoval pomoci wincsp, a vše co zavánělo shelly jsem smazal. od té doby v pohodě.