Byla vydána nová stabilní verze 24.05 linuxové distribuce NixOS (Wikipedie). Její kódové označení je Uakari. Podrobný přehled novinek v poznámkách k vydání. O balíčky se v NixOS stará správce balíčků Nix.
Byla vydána nová verze 1.48.0 sady nástrojů pro správu síťových připojení NetworkManager. Novinkám se v příspěvku na blogu NetworkManageru věnuje Fernando F. Mancera. Mimo jiné se v nastavení místo mac-address-blacklist nově používá mac-address-denylist.
Před 25 lety, 31. května 1999, započal vývoj grafického editoru Krita (Wikipedie). Tenkrát ještě pod názvem KImageShop a později pod názvem Krayon.
Farid Abdelnour se v příspěvku na blogu rozepsal o novinkám v nejnovější verzi 24.05.0 editoru videa Kdenlive (Wikipedie). Ke stažení brzy také na Flathubu.
David Revoy, autor mj. komiksu Pepper&Carrot, se rozepsal o své aktuální grafické pracovní stanici: Debian 12 Bookworm, okenní systém X11, KDE Plasma 5.27, …
Wayland (Wikipedie) byl vydán ve verzi 1.23.0. Z novinek lze vypíchnout podporu OpenBSD.
Craig Loewen na blogu Microsoftu představil novinky ve Windows Subsystému pro Linux (WSL). Vypíchnout lze GUI aplikaci pro nastavování WSL nebo správu WSL z Dev Home.
V sobotu 1. června lze navštívit Maker Faire Ostrava, festival plný workshopů, interaktivních činností a především nadšených a zvídavých lidí.
Webový server Caddy (Wikipedie) s celou řadou zajímavých vlastností byl vydán ve verzi 2.8 (𝕏). Přehled novinek na GitHubu.
Byla vydána verze 3.0 (@, 𝕏) svobodného softwaru HAProxy (The Reliable, High Performance TCP/HTTP Load Balancer; Wikipedie) řešícího vysokou dostupnost, vyvažování zátěže a reverzní proxy. Detailní přehled novinek v příspěvku na blogu společnosti HAProxy Technologies.
Uz nejaku dobu koketujem s Loxone.
27.6.2016 - UPDATE - restyling
Je to centrala "inteligentneho domu". Detaily si kazdy najde sam, v rychlosti len:
Dovody, preco som sa rozhodol pre Loxone ublognem v pripade zaujmu neskor, hlavnym dovodom bola snad ciastocna otvorenost systemu z tych "komercne" dostupnych. Cestou bezdratu typu EnOcean som odmietol ist (aj ked mam v plane par bezdratovych, ale nedolezitych prvkov).
Pribeh dnes zacne od konca - realizaciou vlastneho firmware do modulu Railduino.
Ako uz kdekto koketujuci s Loxone zistil, Loxone ma malo vstupov na tlacitka - nutnost kupit vacsi pocet Loxone modulov - a to ide dost do penazi. Najma pokial pocet tlacitok vyrazne presahuje pocet potrebnych vystupov, je to znacne neekonomicke. 12 vstupov 8 rele - 10k czk :( Rozmyslal som teda, ako to poriesit lacnejsie - na Loxone fore (nez ho zmrazili) boli odkazy na rozne moduly tretich stran. Narazil som okrem ineho na modul Railduino - ceske PLC postavene nad arduinom (s ktorym som laboroval posledny polrok - pouzil som ho ako platformu pre vyvoj seriakom ovladaneho led strip driveru).
Railduino je teda PLC, ma 12 vystupnych rele (max. 220V 5A), 24 digitalnych vstupov na tlacitka a dalsie veci, ktore momentalne nepotrebujem (i2c, pwm mosfet-y, analogove io atd...). Na moje pouzitie je to parada, s jednym max dvomi modulmi pokryjem potrebu vsetkych dodatocnych tlacitok S Loxone sa prepaja bud pomocou ModBus extension (modul Loxone za ~8k), alebo pomocou ethernetu a ModBus TCP.
Kupil som teda jeden kus na pokusy a prepojil to zatial ethernetom. Vysledok ma neuspokojil. Reakcie boli zahadne pomale - reakcia od kliku na tlacitko do zopnutia rele aj v tom najjednoduchsom Loxone plane bola tragicka (1-4 sec). Po dni skumania wiresharkom a kratkej konzultacii s autorom Railduina som dospel k rozhodnutiu vykaslat sa na cely ModBus protokol a komunikaciu s Loxone postavit na obycajnom plain udp broadcaste. To ma podla mna niekolko vyhod a niekolko nevyhod.
Vyhody:
Nevyhody:
*1 Vzhladom na to, ze Railduino je PLC postavene nad arduinom, co nie je ziaden priemyselny standard s mrakmi certifikacii odolnosti voci ruseniu a zivotnosti komponentov (a za adekvatnu cenu samozrejme) a ze elektroinstalaciu chcem postavit tak, aby dolezite veci boli priamo v Loxone a "komfortne prvky" volitelne v produktoch tretich stran som s pripadnou drobnou nespolahlivostou tohoto riesenia zmiereny.
Cely system navrhujem tym sposobom, aby dom dokazal nejak zit aj po smrti akejkolvek "inteligentnej" casti, co znamena:
Pokial dodrzim to, ze cely system bude v jednej izolovanej sieti, kde mi nebude kde-aky windows zasierat siet mrakmi broadcastov, ethernet kabelaz bude len v ramci jedneho racku a nebude roztahana na stovky metrov, neviem aky problem by mohol s udp broadcastami nastat a nemyslim si, ze by mal byt system nejak obzvlast nachylny k chybam. CRC mi poskytne ethernet frame, pokial budu v packete malformovane prikazy, tak sa proste nevykonaju, klik na vypinac proste nerozsvieti svetlo/nevytiahne zaluzie a vzdy sa da klik zopakovat. Otazkou je spolahlivost ethernet modulu pre arduino - ale to sa uvidi casom.
K samotnej uprave firmware:
Kedze som uz nad arduinom staval led driver, tusil som co a ako. Musim povedat, ze posledneho pol roka to u mna na stole sice vypada dost hrozne - po snad 25 rokoch som vytiahol (=kupil) pajkovacku, multimeter a zacal sa od zaciatku ucit to, co ma mala naucit stredna skola (elektro, ta mi moj vstah k elektrike na dlhych 20 rokov dokonale zhnusila a nenaucila ma v tejto oblasti absolutne nic). Plus som dost zacal zas programovat v C-cku :D.
Po chvili dumania a komunikacie s autorom Railduina som sa do toho pustil. Pan Sedlacek - autor tohoto device - bol velmi ochotny a poslal mi zdrojaky jeho firmware, takze som nemusel systemom pokus/omyl lovit, ktore piny arduina su kam zapojene (a nechcelo sa mi to trasovat ani lupou - railduino som samozrejme hned po vybaleni z krabice rozobral k preskumaniu :D).
Po par prvotnych neuspechoch a chaosom ohladne konfiguracie prvkov som zvolil broadcasty priamo na 255.255.255.255. To ma zase vyhody a nevyhody:
Vzhladom na to, ze nie je v ludskych silach normalnym zitim v dome a stlacanim tlacitok vygenerovat taky traffic, ktory by arduino/loxone zahltil, nevyhoda je ciste len teoreticka.
Loxone teda s Railduinom komunikuju pomocou UDP broadcastov na porty 44444 a 55555, pricom Railduino pri zmene stavu digitalneho vstupu broadcastuje command "rail0 i4 1" a po pusteni tlacitka "rail0 i4 0" (cislo za "rail" urcuje adresu, ktore railduino prikaz odoslalo [podla dip switchu na krabici], cislo za 'i' identifikuje digitalny vstup). Loxone na oplatku moze poslat prikaz "rail0 r5 on" a "rail0 r5 off", pricom cislo za 'r' urcuje cislo rele.
A to je vsetko. Neimplementoval som (zatial) ziadne dalsie funkcie railduina ako i2c, pwm vystupy atd... pretoze ich (zatial) nepotrebujem. Ci sa k tomu dostanem, netusim, takze nic neslubujem. Uz toto povazujem ako Java vyvojar za dobry vykon (C-cko som nevidel snad 12 rokov), tak uvidim, ako to bude fungovat.
Cele som to hodil na github aj s example loxone planom predkonfigurovany pre railduino dip switchom nastavene ako '0'. Neparne (liche)) vstupy spinaju rele, parne (sude) rele rozpinaju.
Postupne, ako budem loxone nasadzovat v reali mozno nieco napisem o teplotnych a pohybovych cidlach, nocnom orientacnom osvetleni postavenom z led pasok, multiroom audio postavenom nad raspberry-pi a ovladanom z Loxone a tak podobne.
Tiskni Sdílej:
Pokud někdo zájem o drátové řešení domácí automatizace s vedením na nízkém napětí a samostatných vodičích (bez modulace na 230 V nebo napájecí DC napětí) na trochu slušnější úrovni tak jsem stále přesvědčený, že námi vyvinutý otevřený protokol uLAN je o třídu jinde než většina současných sigle master-slave systémů.
Základní funkce a propojení akcí lze nakonfigurovat přímo do distribuovaných jednotek, takže základní funkce zůstanou použitelné i pokud centrální uzel není trvale zapnutý nebo dojde k jeho selhání. Systém je multimaster, s deterministickou arbitrací přístupu, segment může být i přes 100m dlouhý a jednotky lze připojovat do desítek kusů sběrnicovým způsobem na průchozí linku.
Moje původní motivace bylo použití v laboratorních přístrojích, ale řešení i jiní používají v zemědělství a pokusně i několik domečků bylo jinými na tomto základu automatizovaných. Bohužel nejmasivněji zafinancovaný projekt v této oblasti byl na C# a uzavřený.
Sám na projekt teď čas nemám. Většinou jsme pro malé uzly používali NXP LPC, ale stálo by za to portovat drivery na nějaký levný MCU od ST.
http://ulan.sourceforge.net/Alternativou může být otevřený projekt podle standardu BACnet
http://bacnet.sourceforge.net/