Licznik wody MBUS

[QLQ]

@beku, @pzygmunt coś było robione na svr5 ?

Wczoraj padła mi bramka SVD i dziś postawiłem ją od początku . Niby wszystko działa ale po zapisie w Cloud (publiczny) bramka nie łączy się ponownie tzn jest cały w statusie rozłączona w Cloud.
Wystarczy , ze zmienię nazwę czegokolwiek kliknę "ZAPISZ" , i bramka już nie jest połączona pomimo iż jak się zaloguję na RPI wszystko chodzi. Wiem, ze serwer "resetuje" wtedy wszystko i bramka też powinna się po chwili pojawić jako POŁĄCZONA ale tak nie jest.

Logując się na RPI wszystko chodzi:

Code: Select all

pi@raspberrypi:~ $ supervisorctl status
mi-th-0                          RUNNING   pid 641, uptime 0:18:03
mi-th-1                          RUNNING   pid 640, uptime 0:18:03
mi-th-2                          RUNNING   pid 639, uptime 0:18:03
mi-th-3                          RUNNING   pid 638, uptime 0:18:03
supla-virtual-device             RUNNING   pid 642, uptime 0:18:03

NATOMIAST JAK WYŁĄCZE / WŁĄCZE ZASILANIE czy zrobię REBOOT POJAWIA SIĘ POŁACZONA W CLOUD, normalnie przesyła dane z czujników Xiaomi oraz wodomierzy.

tylko to jedno urządzenie w Cloud nie wstaje jako połączone. Inne po chwili są . O co Kaman

pliki conf:
.

Code: Select all

[GLOBAL]
device_name=BRAMKA RASPBERRY

[SERVER]
host=svr5.supla.org
protocol_version=12

[AUTH]
email=oczywiscie_moj_adr@gmail.com

[MQTT]
host=mqtt.host
port=1883
username=
password=
client_name=supla-virtual-device

[CHANNEL_0]
function=TEMPERATURE_AND_HUMIDITY
file=/home/pi/supla-mi-th/sensor_th0.txt
battery_powered=1
#file_write_check_sec=120

./etc/supervisor/conf.d/supla-virtual-device.conf

Code: Select all

[program:supla-virtual-device]
command=/home/pi/supla-virtual-device/supla-virtual-device
directory=/home/pi/supla-virtual-device
autostart=true
autorestart=true
user=pi

.
/etc/supervisor/supervisord.conf

Code: Select all

[unix_http_server]
file=/var/run/supervisor.sock ; (the path to the socket file)
chmod=0770 ; sockef file mode (default 0700)
chown=root:pi

[Beku]

Nic się nie zmieniło co nie znaczy że może to tak działać/niedziałać. Kod svd nie jest dostosowany do najnowszych źródeł, zresztą Przemek pisał że coś svd za dużo razy próbuje się łączyć do serwera...

[QLQ]

Nic się nie zmieniło co nie znaczy że może to tak działać/niedziałać. Kod svd nie jest dostosowany do najnowszych źródeł, zresztą Przemek pisał że coś svd za dużo razy próbuje się łączyć do serwera...

No to teraz @pzygmunt i @fracz muszą się przyznać co narozrabiali bo SVD po zapisie dowolnego parametru dowolnego urządzenia w Cloud pozostaje rozłączona w Colud do momentu ponownego jej restartu typu reboot czy wl/wył zasilanie
DZIS SPRAWDZILEM - dwukrotnie zainstalowałem od początku SVD do Xiaomi i MBus bo myślałem, że cis skopałem lub źle się zainstalowało ale to raczej wina Cloud. Mam wszystko nana svd5 .
Na chwilę obecną pozostaje restart maliny co np 6h i tyle. Dzieje się tak od wczoraj Przemku i Wojtku.

[Robert Błaszczak]

Dziwne, bo u mnie SVD działa cały czas bardzo poprawnie na dwóch malinach. Cloud publiczny svr14.

[QLQ]

Dziwne, bo u mnie SVD działa cały czas bardzo poprawnie na dwóch malinach. Cloud publiczny svr14.

Tak jak Robert piszesz .. dziala ok ale spróbuj zmienić np temp o 1 st wyedytuj jakieś tam urządzenie i zapisz... zobacz czy malina wstanie tzn czy znów będzie "połączona" w Cloud.

Jak pisałem od wczoraj mam tak: RPI SVD działa w Cloud jak należy ale wystarczy, że coś chce zmienić w parametrach jej czy innego urządzenia. Jak kliknę zapisz to RPI automatycznie mam na czerwono jako ROZŁĄCZONE w Cloud. Dziś 2x instalowałem SVD wg twojego poradnika I dalej to samo. Tak do momentu gdy nie zresetuję RPI..Po tym działa wszysyltko ok...chuchniesz na Xiaomi to w app po 3sek masz inna wilgotność I temp.. ale jak bym znów zalogował się do public cloud i zmienił temp czujnika np o 1 st dowolnego...malina i.jej kanały SVD rozlacxone dopóki nie zresetuję jej. COS JEST NA RZECZY.

Logując się po ssh wszystko ma.RPI hula

Edit. Jak masz wolna SD to sprawdź

[QLQ]

A i jeszcze NAJLEPSZE...DZIS DODAŁEM NA RPI SVD general_purpose_measuerment .Chanel a w cloud pojawił sę grzejnik - cos jest pokiełbaszone valant czy jakiś tak @pzygmunt
.. chlera nie pamiętam ale ten taki oryginalny ... przesuwasz kanał i masz parametry...

Edit. Odpala się komp i zmeniam SD w RPI na instalację SVD z 18.40

[QLQ]

proszę bardzo : plik cfg SVD:

Code: Select all

[CHANNEL_8]
function=GENERAL_PURPOSE_MEASUREMENT
file=/home/pi/supla-mi-th/sensor_th3.txt

a w Cloud :

Clip_6.jpg

.
.
Normalnie jaja jak arbuzy czy ja tylko tak mam ?

[klew]

proszę bardzo : plik cfg SVD:

Code: Select all

[CHANNEL_8]
function=GENERAL_PURPOSE_MEASUREMENT
file=/home/pi/supla-mi-th/sensor_th3.txt

a w Cloud :
Clip_6.jpg
.
.
Normalnie jaja jak arbuzy czy ja tylko tak mam ?

Supla nie wspiera jeszcze kanału ogólnego przeznaczenia. Także może svd wysyła identyfikator kanału, który jest używany do tego grzejnika

[QLQ]

proszę bardzo : plik cfg SVD:

Code: Select all

[CHANNEL_8]
function=GENERAL_PURPOSE_MEASUREMENT
file=/home/pi/supla-mi-th/sensor_th3.txt
@klew proszę tu masz WeMos wg nowych bibliotek w stosunku do SVD o którym j/w piszę
Kanał jest niedostępny

a w Cloud :
Clip_6.jpg
.
.
Normalnie jaja jak arbuzy czy ja tylko tak mam ?

Supla nie wspiera jeszcze kanału ogólnego przeznaczenia. Także może svd wysyła identyfikator kanału, który jest używany do tego grzejnika

No nie do końca bo jak na WeMos mam taki kanał do sprawdzenia to jest jako "kanał nie obsługiwany"

Clip_8.jpg

Clip_7.jpg

[QLQ]

Chopaki jaka komenda czyni że RPI będzie się restartować np co 1 h?