Příspěvky

1

Vývoj / Re:Spinanie relatka z Raspberry Pico

« kdy: 19. 02. 2022, 19:48:55 »

Bolo by toto funkčné a bezpečné riešenie?

Jedine zarucene bezpecne reseni je to, ktere udava datasheet - tj. mezi 3 a 6 ma byt spinaci prvek.

Kdyz to pripojis opacne, budes mit pravdepodobne na pinu 6 neco kolem tech 24V, kteryma to Raspberry spolehlive odpalis.

2

Vývoj / Re:Spinanie relatka z Raspberry Pico

« kdy: 18. 02. 2022, 16:49:26 »

Optočleny by byly určitě lepší (velikost, spolehlivost, trvanlivost), ale jestli je důraz spíš na tu jednoduchost zbastlení a relátka by nevadila, tak Seeed má relátkové moduly řízené pomocí I2C, takže k připojení všech relátek stačí 4 dráty včetně napájení. Moduly mají změnitelnou adresu, jde jich použít až 128 na jedné sběrnici.

Mám od nich osmirelátkovou verzi, imho slušně provedenou, ale ta už se myslím neprodává. Na webu vidím čtyřrelátkovou verzi: https://www.seeedstudio.com/Grove-4-Channel-SPDT-Relay-p-3119.html

Celkově by teda přes 4 dráty snad mělo jít ovládat 512 relátek

Bacha, u Seeed produktů je potřeba hledat "Grove", ne "I2C" (to je jejich komerční označení konektoru a sběrnice, ale je to normální I2C).

3

Vývoj / Re:Home Automation / Machine learning

« kdy: 18. 02. 2022, 09:58:59 »

určitě se chci dané tému věnovat, více nastudovat a pak zkusit aplikovat na ta data co neustále sbírám. Možná selžem a možná uspěju.

Hodne stesti! ... and keep us informed

P.S. Jeste me napadlo, ze pokud ses vic takovej experimentalni/hackerskej typ (cemuz by konstrukce vlastnich sensoru nasvedcovala), tak jeste jinej moznej pristup je udelat si radost nejakym vylozene hands-on pokusem, kterej bude mit vyrazne uzsi zadani, nebude moc inovativni, ale zase si u nej dobre vyhrajes. Ted mi treba shodou okolnosti v emailu pristalo upozorneni na tenhle projekt: https://www.hackster.io/kutluhan-aktar/o3-enabled-ble-weather-station-predicting-air-quality-w-tf-ee1c37
Docela pekny. Sice edge computing, coz asi uplne nechces, ale skvelej pokus. A zkusenost s Tensor Flow je skvela, ta se ti rozhodne hodit bude i u pripadnyho dalsiho "vetsiho" projektu.

4

Studium a uplatnění / Re:Práce pro německé a rakouské společnosti

« kdy: 18. 02. 2022, 06:26:44 »

to je obecne nemecka bolest, skvele vedeni, inteligentni lidi, ale pak sahnou vedle a zacnou stavet krematoria.

Získáváš platinového bludišťáka za nejlepší vtip na Rootu za posledních 5 let! Ještě že jsem při čtení nejedl, jinak bych to měl všude

5

Vývoj / Re:Home Automation / Machine learning

« kdy: 17. 02. 2022, 18:24:45 »

P.S. Pokud jsem te od toho zameru neodradil, tak sem urcite po nejake dobe napis, jak postupujes, muze to byt dobra inspirace pro ostatni.

6

Vývoj / Re:Home Automation / Machine learning

« kdy: 17. 02. 2022, 18:23:26 »

Ok, tak s tim by se pracovat dalo, minimalne si pekne pohrajes. Byl bych teda dost skepticky k moznosti nejakeho vyrazne zajimaveho vysledku, ale pro uceni dobry a treba v prubehu zkouseni cile predefinujes na neco trochu realistictejsiho

Dekuji, urcite se na to podivam.

K problematice ML existuje strasne moc materialu a bez studia aspon zakladnich pojmu/konceptu nema vubec smysl se o neco pokouset. xyz uvedl spravny klicovy slova. Ke kazdemu tomu konceptu existuje nekolik ruznych implementaci. Je potreba si nastudovat alespon highlevel, jake maji vlastnosti (jake vyzaduji vstupy, jake realisticky muzou nebo nemuzou poskytnout vystupy apod.).

Nastesti uz existuje dost nastroju, se kteryma se da hrat i kdyz clovek zna fakt jenom zaklady. Neni nutne potreba znat detaily implementace jednotlivych metod, na to uz je fakt dostatek knihoven a/nebo i klikacich nastroju.

influxdb

InfluxDB ma pro ucely analyzy dat nectnost v tom, ze je dost komplikovane az nemozne z nej rozumne dostat vetsi objemy dat. Nastesti v tom tvem pidiobjemu se to nejspis vubec neprojevi. Trochu prace budes mit s dostanim dat do potrebneho tvaru, ale velky plus je, ze sql i influxdb ti aspon zaruci spravne typy dat per measurement, nemuze se ti stat, ze bys tam mel nejake vylozene smeti...

Pokud je to algoritmus, ktery jsi naprogramoval, v cem spociva ta nejistota?

nejistota je hlavně k příkladu v případě, že to algoritmu vstupuje počasí, nebo jsou mezní hodnoty barevných proměnných, např. připadne-li akce na den, kdy je podle kalendáře státní svátek a systém neumí s jistou říct, že přijdou popeláři a je třeba otevřít branku pro popelnici

To neni nejistota. Bud algoritmus vi, ze je svatek a ve svatek popelari nejezdi, takze (spravne) branku neotevre, nebo to nevi a branku (chybne) otevre. To je mozna chybejici vstup nebo nedokonaly algoritmus, ale ne nejistota. Nejistota je, kdyz ti treba predpoved pocasi rika, ze za tri dny bude kolem poledne prset, ale je to jenom s 60%ni pravdepodobnosti.

chápu, ale věřil jsem, že se už někdo něčím podobným zabýval a nasměruje mě konkrétně. Ale asi jsem se mylil, a možná to celé je blbost. Ale před tím, než to úplně zavrhnu si o tom chci co nejvíce nastudovat a popřípadě otestovat na jednoduchých usecase

Neni to blbost. Ale je to prilis velke sousto a existuji konkretni argumenty, proc se lze opravnene domnivat, ze to nebude uspesne tak, jak si to predstavujes

Kazdou aplikaci ML musis zacit tim, ze si udelas poradek ve svych myslenkach. Co bych vlastne presne chtel, aby ten system umel? Ma umet zapnout topeni pul hodiny pred tim, nez obvykle prijizdim domu (aniz bych mu rikal, kdy to je - sam si to rozpozna)?  Ma umet stahnout markyzu pul hodiny pred tim, nez zacne vitr? apod.

Tohle zabere dost casu a neni moc jasny, jak presne to udelat. Fantazii se meze nekladou, ale cim min mezi, tim z toho vypadne slozitejsi a hur uchopitelne zadani.

Mne osobne prijde strasne inspirativni pribeh, jak Jeff Hawkins vymyslel PDA. Udelal si dreveny model sve predstavy PDAcka a kdyz mel nejakou schuzku, tak predstiral, ze si tam zapisuje poznamky, udalosti do kalendare...[1] Pecka jak svina!

Mozna bych takhle nejak zacal i s tou analyzou HA. Predstirej, ze nejaka genialni AI neco s tim barakem sama dela. A zapisuj si, co a kdy udelala. Treba ti z toho nejaky dobry zadani vzejde. Anebo taky uz v tehle fazi zjistis, ze cela ta myslenka je pitomost. Coz je taky cennej objev

Kazdopadne v zadnym pripade nedoporucuju cestu "tady mam nejaky data a neco s nima chci delat". To nikdy nikam nevede, je to zarucene slepa cesta, mnohokrat overeno mnoha lidmi a projekty...

[1] viz napr. https://albertosavoia.medium.com/the-palm-pilot-story-1a3424d2ffe4

7

Vývoj / Re:Home Automation / Machine learning

« kdy: 17. 02. 2022, 15:08:14 »

Ja bych o tom moc rad diskutoval, ale priznam se, ze stejne jako kolegove vidim par konkretnich varovnych signalu a vzhledem k tomu, ze to je fakt slozite tema, nerad bych travil hafo casu rozepisovanim se v diskusi o nicem...

Tak zatim teda aspon heslovite a uvidi se, jestli ma smysl pokracovat:

Mám spoustu dat ze všech komponent, tato data bych rád využil k analyze a výuce AI, následně bych propojil AI a můj software řídící HA.

Jak jsou ta data ulozena (uloziste, popr. format)? Jake mas zatim analyzy (predpokladam, ze alespon grafy)? Cim delas ty dosavadni analyzy a cim je vizualizujes?

pokud zarízení nepodporuje přímo MQTT

Mohl bys pls pro priklad uvest pet konkretnich zarizeni (tj. vyrobce a model), ktera primo podporuji MQTT?

mnoho algoritmů pracují is více než 10 proměnnými aby dokázaly vhodně reagovat.
dokonce jsem systém odladil tak, že když není 100% jistý,

Pokud je to algoritmus, ktery jsi naprogramoval, v cem spociva ta nejistota?

nerozumím proč rozporujete validitu mé otázky, resp. prosby o doporučení

Ja bych ji zpochybnoval hlavne proto, ze staci jeden dotaz do googlu a vypadne ti takovych sluzeb nejmin pet na prvni strane. Nepises nic o tom, ze ses na nekterou z nich dival, co se ti na ni nezdalo, jak jsi ji zkousel aplikovat apod. Nezminujes o literature, kterou jsi o tematu zatim nastudoval, ani nezadas zadnou doporucit.

Aplikace ML v jakekoliv oblasti je dost komplikovana vec a v tehle domene to neni ani tak komplikovane jako spis sci-fi. Takze uprimne receno, necekal bych, ze by se cokoli kloudneho podarilo udelat v tehle oblasti nekomu, kdo neni schopen zadat dotaz do googlu... Sorry za uprimnost.

Nezádám navod step-by-step, stačilo by vodítko napr. na analyzu dat s možností detekce vzoru zkus tohle, pro ML a typ dat je zase tahle knihovna pro python

https://letmegooglethat.com/?q=data+analysis+tools+online
https://letmegooglethat.com/?q=python+ml+library

8

Vývoj / Re:Kterým směrem se vydat od C

« kdy: 11. 02. 2022, 15:59:24 »

v dokumentaci k Rustu bude určitě vysvětlen u traitů rozdíl mezi oběma přístupy.

Jj, https://doc.rust-lang.org/rust-by-example/generics/assoc_items/the_problem.html a následující (14.8.2).

Je to zajímavý, neznal jsem, dík za upozornění.

9

Vývoj / Re:Kterým směrem se vydat od C

« kdy: 11. 02. 2022, 13:01:01 »

Jen rychlej dotaz: to jako obecně, nebo v kontextu Go?

V Go. Ale ani tam to neplati, prehlidl jsem to.

10

Vývoj / Re:Kterým směrem se vydat od C

« kdy: 11. 02. 2022, 12:57:16 »

V Go se pomoci embedded struct da udelat "skoro jako dedicnost". Ale nektere vlastnosti dedicnosti to z principu mit nemuze. Napriklad prekryvani implementace v potomkovi. Jak rikam, mel jsem na to nekde explicitni priklad, ale fakt nevim, kam jsem ho zasantrocil

Tak jsem nasel aspon vlakno, kde jsme se o tom bavili tady: https://forum.root.cz/index.php?topic=21149.msg310669#msg310669 (plus navazujici prispevky)

Tenhle priklad neni uplne na kost orezana demonstrace toho, co mam ted namysli, ale ta podstata je tam stejna.

11

Vývoj / Re:Kterým směrem se vydat od C

« kdy: 11. 02. 2022, 12:49:41 »

A skoro mám chuť slovíčkařit a zeptat se, co přesně je ta "opravdová dědičnost". Ale jen skoro

V Go se pomoci embedded struct da udelat "skoro jako dedicnost". Ale nektere vlastnosti dedicnosti to z principu mit nemuze. Napriklad prekryvani implementace v potomkovi. Jak rikam, mel jsem na to nekde explicitni priklad, ale fakt nevim, kam jsem ho zasantrocil

12

Server / Re:CentOS - CPU mining

« kdy: 11. 02. 2022, 12:44:37 »

Zadat do Googlu "CPU mining", procist prvnich dvacet odkazu a pak se zeptat na konkretni veci, ktery ti nebudou jasny.

13

Vývoj / Re:Kterým směrem se vydat od C

« kdy: 11. 02. 2022, 12:37:52 »

Querier nemuze byt rozhrani, protoze rozhrani nemuzou byt typove parametrizovana, pokud se nepletu.

Pleteš.

Máš pravdu, v tom dlouhým proposalu jsem to z rychlíku přehlídl. Tímpádem teda jo, dala by se fakt napsat factory factoriovitější

Nicméně teda fakt škoda té chybějící parametrizace/přetěžování metod, tohle by bylo hezký, kdyby šlo: https://go.dev/play/p/ikNP4ZIEqx_u?v=gotip

14

Vývoj / Re:Kterým směrem se vydat od C

« kdy: 11. 02. 2022, 10:21:50 »

Aha, už myslím začínám tušit, kde se naše pohledy liší. Já na to koukám jako čtenář kódu. A že tam zrovna není nic, co by to přede mnou _opravdu_ schovalo. Jo, kdyby to querier bylo jen rozhraní a padalo ven z nějakého blackboxu, tak bych ten blackbox za továrnu považoval.

Querier nemuze byt rozhrani, protoze rozhrani nemuzou byt typove parametrizovana, pokud se nepletu.

Já vidím struct, který se přes tečkovou notaci předává jako první parametr nějaké sadě funkcí. To prostě vypadá a kváká jako C++/C#/Java třída. A mám pocit, že je i cílem aby to tak co nejvíc kvákalo, ať to není matoucí.

Vypada to tak jenom syntakticky, jinak se to ve spouste veci lisi.

Napr. mechanismus tzv. "embedded structs" sice pripomina dedicnost, ale pri predavani "predka" se predava jenom skutecne ten embedded struct, takze se pomoci toho opravdova dedicnost udelat neda. Jednou jsem na to napsal explicitni priklad, ale ted ho nemuzu najit

No a konkretne tady nema smysl mluvit o "instanci konkrétní generické třídy". To, co je vraceno, je proste struct. Na jeho definici nic "generickeho" neni   A v Go to ani jinak nejde. This is the way

15

Vývoj / Re:Kterým směrem se vydat od C

« kdy: 11. 02. 2022, 09:40:02 »

v podstatě jen vážou typovou proměnnou pro budoucí volání, nic nového se nevytváří (je to jen wrapper pro compile time, žádnou paměť navíc nezaberou).

Z high-level pohledu ani neni duvod, aby neco zabiraly. V min omezenem jazyce by parametr ani nebyl fixovany, cili by nebylo co vytvaret...

Mas nejaky odkaz na zdroj, ze skutecne nic nezabiraji realne? (Dovedu si predstavit nejaky implementacni duvod, proc by tomu tak nemuselo byt).

Tak jistě, je to něco zcela jiného

Znovu: v cem? (Nehadam se, ale proste tam zadny zasadni rozdil nevidim)

Co potkávám továrny, tak obvykle neprodukují nějaké konkrétní objekty, ale "něco" co má nějaké rozhraní. Takže ta továrna je mezivrstva, díky které nevím, co vlastně přesně dostanu.

Jo, to jsem zapomnel zminit, to tady ale taky plati. V tom prikladu https://rakyll.org/generics-facilititators/ muze byt struktura Querier kldne neexportovana.

Ty facilitátory ani nepadají z nějaké továrny - vznikají jako instance nějaké konkrétní generické třídy. A ani z nich nemusí padat nějaké výsledky - může to být třeba zapisovač řádků do databázové tabulky.

Go nema "tridy". A to NewQuerier je sice semanticky konstruktor, ale na urovni jazyka je to libovolna typove parametrizovana funkce, ktera typ zafixuje do structu. Volajici vubec nemusi vedet, co ten struct, ktery dostane, obsahuje. Vi jenom, ze jsou na nem nadefinovane nejake metody.