"Zase" vytěžování - automatizace.

[Ivo12s]

Zdravím,
pro mé základní vytěžování - topná spírála v bojleru - používám jednoduchou logiku

- RPi 4b + Relay Hub + aplikace Python v RPi
+ WiFi Relay Tuya Module 5-32V WiFi Switch
+ Tuya Mini WiFi Switch Module

+ aplikace Smart Life

RPi a celý FVE systém mám tři patra od bojleru.
Systém funguje jen na bázi SOC. Když se baterie nabije do skoro MAX, Python aplikace monitoruje, sepne relé, které na WiFi modulu Tuya zapne aktivní stav a kvůli ničemu jinému tam není, jen aby se ve Smart Life vědělo, že bylo dosaženo MAX napětí. Ten tedy zjistí online aplikace Smart Life a podle mého jednoduchého prográmku sepne Tuya Mini Wifi modul u bojleru. No a ten je přímo v zásuvce u bojleru. Tedy celé tohle řešení funguje přes lokální WiFi a tu jsem už k bojleru dostal dávno. Samozřejmě ta aplikace v Pythonu hlídá napětí zase pro vypnutí, mám tam i samostatnou část pro nucený doohřev ručním sepnutím v aplikaci atd.

Funguje to jednoduše. Nicméně občas dojde k výpadku aplikace Smart Life a občas k výpadku Wifi spojení - je to přes WiFi opakovač. No a hlavně mi začíná vadit, že to funguje jen díky nějakému externímu serveru bůh ví kde. Takže uvažuji o nějakém vlastním řešení. Ale kde začít? Tady je toho spousta - HomeAsistant, NodeRed atd. atd.

Nasměrujte mě prosím někdo - základem řešení by mělo být, že spínač pro bojler bude dostupný přes WiFi a tedy něco jako to Tuya Mini WiFi Swith.

Díky předem.

[rva]

Začal bych s shelly. Funguje i bez cloudu a dá se integrovat třeba do Homeassistant.

[Ivo12s]

Tak jestli jsem v rychlosti pochytil správné a jednoduché řešení:
Koupím si 2x Modul Shelly 1 Plus, spínací, WiFi (SHELLY-1-PLUS)

Ten první budu napájet z 12V a spínací vstup zapojím na rele HAB co mám na RPi. Možná můžu vyhodit ten Relé HAB a spínat to rovnou přes GPIO na RPi, protože ten kontakt spíná do nuly. Ale zatím tedy s galvanickým oddělením. A stejně jako nyní - výkonovou část vůbec nepoužiji, bude to jen signál, co se děje.
Ten druhý strčím do krabice u bojleru s napájením 230V a výkonová část bude spínat ten bojler.

Aplikace v RPi zůstane stejná a jediné, co se změní, že můžu ty dvě Shelly propojit "mirroring" v jejich vlastní aplikaci přes domácí WiFi a nemusím to propojovat na Cloud.

Dotaz - a nebylo by od Shelly něco jako náhrada toho prvního Shelly 1 Plus, které má externí vstup a nebo třeba měření napětí, ale přitom slouží jen na indikaci? Tam tu výkonovou část nevyužiju. S napájením 12V.

[rva]

Shelly uni? Já tím měřím 4 teploty.

[Ivo12s]

To by šlo. Já tušil, že z toho zase bude šelmostroj.

Akorát se tím dostávám do další zatáčky. To moje RPi mi také měří okolní teplotu a když se to blíží k nule, zapne topení pro baterky. Baterie potom mají každá vlastní termostat a v tom rozmezí nad nulou si to už řídí samy.
Takže se pomalu dostávám do situace, že s SHELLY UNI bych měřil RPi spínací kontakt (napětí baterek by muselo být přes dělič, umí jen do 30V) - kvůli vytěžování - ale také i okolní teplotu.
A tou výkonovou částí z Shelly 1 Plus bych napájel topení baterkám.

A místo programování v Pythonu se budu učit tvorbu scénářů u Shelly

[Migel]

Len sa spytam..nepouzivas nodered?...podla mna by to islo spravit v tom...

[rva]

U shelly scény nepoužívám, protože vše řeší Home assistant. Ale tuším, že scény se ukládají na cloud a pak by bez internetu nefungovaly.

[Ivo12s]

U shelly scény nepoužívám, protože vše řeší Home assistant.

No právě. Takže čisté a správné řešení by byla instalace Home Assistant a nebo se naučit NodeRed.
Nikde nemůžu najít nějaký návod, jak funguje ta Shelly App, ale odpověď na dotaz tvrdí, že by to mělo fungovat s tvorbou scénáře:

Když vytvoříte scénář v Shelly App a uložíte ho do modulu Shelly 1 Plus, bude fungovat nezávisle na Cloudu nebo mobilním telefonu, ve kterém byl scénář vytvořen. Modul si pamatuje nastavení a provádí akce podle scénářů i bez připojení k internetu.

Co se týče druhé otázky, ano, můžete pracovat s postupem, kdy se scénář vytvoří v rámci účtu na Shelly Cloud, ale pak se uloží přímo do zařízení. Tímto způsobem není Cloud potřeba pro provádění scénářů. To je užitečné, pokud chcete minimalizovat závislost na externích službách.

[rva]

No vidíš. Shelly jsou dobrá a spolehlivá zařízení, třeba zjistíš, že splňují vše, co potřebuješ.

[Ivo12s]

Ještě bych zůstal u tématu a rozšířil ho s dotazem na znalce Raspberry.
Prográmek v Pythonu 3 na vytěžování provozuji na Raspberry Pi 4B na kterém je instalován systém Bullseye. Aktuálně je ale již nějakou dobu k dispozici nový systém Bookworm. Ty prográmky tam mám dva. Jeden se stará o vytěžování a jeden zapíná napájení topení do bateriových boxů. Ty prográmky si čtou napětí z Victron Venus a na teplotu je tam krátký kus kódu a teplotní čidlo DS18B20 a postupem. Všechno funguje jak má (IT poučka = funguje to? Nešahej na to ). Pokud budu HW měnit za Shelly, chtěl jsem aktualizovat i systém RPi.
Na záložní USB jsem načetl nový systém, rozběhal SSH i VNC, přetáhnul adresáře s Python programy. A předpokládal, že si je budu v testovacím prostředí pouštět a zjistím, jestli jim něco chybí. Zasekl jsem se skoro na začátku - prográmek na topení začíná sekvencí

Kód: Vybrat vše

import RPi.GPIO as GPIO
import json
import os
import glob
import time
from pymodbus.constants import Defaults
from pymodbus.constants import Endian
[b]from pymodbus.client.sync import ModbusTcpClient as ModbusClient[/b]
from pymodbus.payload import BinaryPayloadDecoder

a Python hlásí, že na řádku 21 je chyba. Tam je ten zvýrazněný kód. Vyhledáváním jsem pak zjistil, že

Pymodbus.client.sync no longer exist it is now Pymodbus.client. You also have not installed serial_asyncio. There are (as noted) a number of important changes between 2.5.3 and 3.0.0 (as signalled by the change 2 -> 3) and you need you need to modify your script and environment accordingly.

Chápu, že bych měl aktualizovat ten začátek podle nově dostupných modulů, ale to je pro mě na několik zimních večerů. Uměl by si nějaký dobrodinec s tímhle poradit? Podotýkám, že nechci práci zadarmo. To jen že v tuto chvíli vůbec netuším, jak moc složité to předělání je, jestli to má smysl dělat a takže za mě se vracím k té zmíněné poučce nahoře. Ale kdyby někdo věděl co a jak, bylo by to super. Prográmek dávám do přílohy. Dělal jsem ho sám po několika hodinách s příručkou Python snadno a rychle, tak prosím berte ohled na kvalitu a strukturu kódu...Třeba se to bude někomu hodit.

Díky předem.

[Ivo12s]

No vidíš. Shelly jsou dobrá a spolehlivá zařízení, třeba zjistíš, že splňují vše, co potřebuješ.

ANO, splňují... I když je to relativně jednoduché, tak jsem s tím dnes bojoval celé odpoledne.
Takže jako obvykle = pro případné následovníky poznámky z boje:

• Použil jsem 2x Shelly Plus1 prostě proto, že to je totožné zapojení jako jsem měl, časem možná...

• Zařízení sice spolu komunikuje po LAN síti, ale pokud chcete vyřadit CLOUD, vyžaduje totožnou WiFi včetně názvu sítě. Komunikace přes WiFi Extender s jiným názvem "podsítě" se rozpadne

• při experimentech nechte zapnutý Bluetooth, bude se vám hodit až se zařízení odpojí a budete potřebovat znovu nahodit síť a nebo Cloud

• Scénáře vytvořené na Cloudu jdou docela jednoduše vytvořit i otestovat... Jsou vám ale na dvě věci bez Cloudu. Výše uvedená odpověď je trochu zavádějící. ANO, scénáře mohou být nezávislé na Cloudu nebo mobilním telefonu. Ale musíte si ho vytvořit samostatně v WEB prostředí zařízení. Není tam funkce, která by ho nějak exportovala z Cloudu do zařízení.

• Prostředí tvorby scénáře v Cloudu je jiné i trochu co do logiky věci, takže jsem si na Cloudu vyzkoušel, že to jde udělat, ale pak jsem to stejně tvořil celé znovu.

• zapnutí Spínače č.2 v Cloudu jde nasimulovat logikou. Na lokální síti musím použít HTML příkaz. Jednoduchý, ale nenašel jsem způsob, jak to udělat jinak - http://192.168.x.xx/relay/0?turn=on

• časový interval Spínače č.1 [topení na pevno bez závislosti na baterii]nejde "poslat" do Spínače č.2 jen jako příkaz. Musím ho nastavit jako interval Spínače č.1 a ten pak monitorovat pro sepnutí č.2. Na dálkové ovládání totiž stačí monitorovat jen ovládací kontakt "Spínače č.1". Na interval ale ovládám výstup a ten pak můžu zase poslat do č.2. Časem to ještě učešu.
  Je to trochu šroubovaný takže :
  - logika pro Python program vytěžování = Spínač č.1 monitoruje stav ovládacího kontaktu a když je sepnuto, pošle příkaz k sepnutí do Spínače č.2
  - logika pro časový interval do-ohřívání = Spínač č.1 má nastavený interval sepnutí vlastního relé a když je toto relé sepnuto, pošle příkaz k sepnutí do Spínače č.2

Ale i tak výsledek je takový, jaký jsem chtěl = dvě IP zařízení IoT fungují na lokální WiFi síti, jsou nezávislé na Cloudu, jdou ovládat přes vypínač, můj Python software i přes lokální WEB rozhraní. Takže spokojenost. A děkuji za nasměrování.

[rva]

Gratuluji. Malý krok pro lidstvo, ale obrovský skok člověka. Nebo naopak?

[Ivo12s]

Ještě doplním. Aplikace Shelly v mobilním telefonu, pokud je na stejné Wifi, tak na ty spínače (po nějaké chvíli) vidí i bez Cloudu, umí je i ovládat jako tlačítka. Nicméně náhodně nesdílí správný stav spínače - po dálkovém zapnutí pořád hlásí, že je vypnuto, přitom WEB interní rozhraní potvrzuje zapnutí. A testovací scény vytvořené v mobilní aplikaci mi nechodí. Takže bez Cloudu jedině v tom interním WEB rozhraní. Ale jestli je to zařízením, nebo rukama, to jsem ještě nevyzkoumal.

[Ivo12s]

Ještě tedy k tomu Bookworm. Nakonec to nebylo zase tak komplikované. Program opravdu potřebuje jen předělat
z from pymodbus.client.sync import ModbusTcpClient as ModbusClient
na from pymodbus.client import ModbusTcpClient as ModbusClient

a pak jsem tam měl nějaké proměnné a upravit cron, ale za jedno odpoledne je nový systém i s funkčními podprogramy hotov.

[dusanmsk]

ivo praskni ten kod do chatgpt a pobedz mu aby to prepisal na novy pymodbus. A doinstaluj si baliky co ti chybaju, napr.ten async serial.

[Ivo12s]

No jo, to mě fakt nenapadlo... člověk se musí pořád učit. I teď jen je to "jak používat AI". Každopádně mě už to funguje, něco jsem se přiučil o rozdílech Bookworm a Python hlásí, že kód je v pořádku, Takže super.

[dusanmsk]

Bookworm je len novsia distribucia debianu a su v nej novsie baliky. A debian je ultrakonzervativne distro, kde sa ti kludne stane, ze medzi verziami sa nejaka moc agilna technologia prepise od zakladu 2x
Tebe sa proste upgradol python tak to bolo treba narovnat.