Poslední příspěvky

1

Software / Home Assistant a pouzitelnost speech-to-phrase (cestina/slovencina)

« Poslední příspěvek od jose1711 kdy Dnes v 14:35:01 »

Ahoj,

na ovladanie domacnosti pouzivame prevazne Voice PE s LLM-based (Gemini, free account) konverzacnym agentom (STT obstarava HA cloud subscription). Uz par mesiacov nas ale frustruje odpovedami "internal error, check quota (kvota OK), bla bla, kopec zlozenych zatvoriek, kodov atd" - po zopakovani prikazu uz vacsinou zareaguje bez citania chybovej hlasky.

Kedze HA bezi na maline, lokalne LLM velmi do uvahy nepripada a vymanenie z cloudu by bol len bonus. Pozeral som, ze speech-to-phrase podporuje aj cestinu, no neviem, ci by mi to vytrhlo trn z paty.

Mate s tym niekto skusenosti?

Dik, j

2

Windows a jiné systémy / Re:Skok systémového času Windows

« Poslední příspěvek od jardaplc kdy Dnes v 13:47:06 »

Tak potvrzeno, v ESXi byl o těch 46 minut špatný (neudržovaný čas). No a když denní drift  je asi -0,8 vteřiny, server jsme pořizovali zhruba před 2,5 lety, tak to krásně vychází, že se od té doby posunul zhruba o 15 minut dozadu. No a jelikož při pořízení byl letní čas, tak proti aktuálnímu času je to těch 45 minut dopředu.
<Facepalm>
Mohlo mě to napadnout dřív, než jsem tady začal plašit; ale diskuze byla myslím alespoň pro mě docela poučná.

Jako anekdotu na závěr můžu zmínit, že virtuálku jsme používali interně ve firmě na vyčítání události z Jablotroní sběrnice (příchody / odchody lidí dle pípnutí karty). Takže lidi, co měli to štěstí a přišli před tím, než si virtuálka ráno chytla správný čas, měli občas zvědavé dotazy, proč mají v systému příchod v 7:46 kyž si pípli v 7:00 

3

Sítě / Populárně naučná literatura pro záčínajícího síťaře

« Poslední příspěvek od kopevi2 kdy Dnes v 13:33:03 »

Zdravím všechny do nového roku.
Chtěl bych Vás poprosit o tip na knížku, kde by byly shrnuté základy (a věci které je dobré vědět) ohledně síťařiny.
Něco jako byly knížky od pana Krčmáře  - Linux tipy a triky pro bezpečnost apod. ale aktuální v této době. Docela by mi to bodlo, v nastavování soukromých DNS pro intranet doma (otevření určitých služeb do internetu, bez VPN - galerie apod..). Bohužel času je málo (tyto věci jsou pouze můj koníček), něco jsem si nastudovával, ale přijde mi, že pořád někde přešlapuji a úplně nevím jak správně dál např. jak vlastní "server" s proxmoxem nadrátovat korektně na VPS s DNS -> tzn. abych se do galerie dostal skrze internet např. galerie.example.com apod...

Zatím jsem to řešil tak, že jsem dělal WG tunely na VPS a uživatel se přihlásil na VPN a pak dal IP zařízení atd. Zatím mi to vyhovovalo, ale část rodiny neumí s WG pracovat, takže to trochu komplikuje situaci.
Máte prosím nějaký tip? Bylo by to zajímavé i pro mého sysnovce, který je teď na průmce, aby si prohloubil znalosti a já bych měl pro něj taky pěkný dárek k narozkám :-) .

Děkuji moc za pomoc..

4

Windows a jiné systémy / Re:Skok systémového času Windows

« Poslední příspěvek od Marvin kdy Dnes v 13:23:30 »

VMware potřebuje čas z hostitele při událostech boot/suspend/resume/snapshot, když musí posunout virtuální RTC a TSC o čas, kdy host spal a virtualizovaný OS o tom neví.
HPET VMware emulovat neumí.

5

Sítě / Re:Statická IPv4 a IPv6 PD na DOCSIS síti

« Poslední příspěvek od hlp84939 kdy Dnes v 12:50:34 »

Převodníky se aktuálně dodávají pouze business zákazníkům (u nich je automaticky veřejná pevná IPv4 a IPv6 součástí služby). Ovšem pozor, smlouva se uzavírá na 24 měsíců a tedy případná změna na nižší tarif nemusí být ze strany VF akceptována (a u business samozřejmě není ochrana v podobě měsíční výpovědní lhůty jako u běžných koncáků).

6

Windows a jiné systémy / Re:Skok systémového času Windows

« Poslední příspěvek od Marvin kdy Dnes v 12:45:23 »

Takže mi z toho vychází, že je špatně buď systémový čas v ESXi, nebo zmiňovaný offset (minimálně) pro tuto virtuálku. Čekám až se mi ozve admin. Skoro bych tipnul, že se u nás na firmě zprovoznil server, nastavil se čas a pak na to roky nikdo nešáhnul, ntp nebylo zapnuto, no a čas vesele driftuje o tu 0.8 vteřinu denně (což mi ale přijde docela dost). Ale třeba se pletu.

Vypadá to na neudržovaný čas na hostiteli.
Přesnost krystalu bez teplotní kompenzace je 10-50ppm, drift 0.8s/den je ještě dobrý výsledek.

7

Hardware / Re:Počítač se nezapne se zařízeními v USB

« Poslední příspěvek od redustin kdy Dnes v 12:36:03 »

IMO je tahle oblast docela komplikovaná. AI mi říká, že OTG USB-C nesmí připojit VBUS portu k napájení, dokud nezdetekuje Rd na CC lince - tj. připojené device. Současně ale signalizuje svůj "intent" hostitele připojením Rp CC na interní +5V, aby druhá strana viděla, že chce být hostitelem. Toto připojení nemá být trvalé, ale pravidelně to má odpojovat, aby mohl zdetekovat, že druhá strana chce také být hostitelem (jinak nemůže poznat Rp na druhé straně, protože by byly obě strany připojené Rp na 5V).

Ale současně AI říká, že každý hostitel by měl před sepnutím napájení do VBUSu zkontrolovat, zda druhá strana tam neposílá napětí. To platí i pro USB-A hostitele které nemají žádnou CC na komunikaci. Současně musí zajistit, aby se přicházející napětí z portu nedostávalo dál do zařízení.

Tudíž mi přijde, že v tomto případě jsou na vině obě zařízení - ten Rode nemá aktivovat VBUS, dokud na CC nevidí device, a ten PC host (který má USB-A  a tedy VBUS pod napětím před připojením Rode) by měl zabránit příchozímu proudu jít dál do PC (natož se z portu nechat napájet).

Ale pak chápu, že se dobře udělané PC odmítne spustit, když na USB portu zdetekuje příchozí VBUS, což tam nemá co dělat (OTG USB-C Rode to tam nemá co pouštět).

Ale možná jsem to pochopil blbě...

8

Windows a jiné systémy / Re:Skok systémového času Windows

« Poslední příspěvek od jardaplc kdy Dnes v 12:22:01 »

Povedlo se mi reprodukovat skoky, k posunu dojde i když ručně vypnu a zapnu servicu vmtoolsd. Po naběhnutí okamžite skok.
Z debug logu

Kód: [Vybrat]

...
[2026-01-08T17:10:29.805Z] [   debug] [vmtoolsd] [13096] Setting option 'synctime.period' to '0'.
[2026-01-08T17:10:29.805Z] [   debug] [vmtoolsd] [13096] Setting option 'time.synchronize.tools.enable' to '1'.
[2026-01-08T17:10:29.805Z] [   debug] [vmtoolsd] [13096] Setting option 'time.synchronize.guest.resync' to '0'.
[2026-01-08T17:10:29.805Z] [   debug] [vmtoolsd] [13096] Setting option 'time.synchronize.guest.resync.timeout' to '0'.
[2026-01-08T17:10:29.805Z] [   debug] [vmtoolsd] [13096] Setting option 'time.synchronize.tools.startup.backward' to '0'.
[2026-01-08T17:10:29.807Z] [   debug] [vmtoolsd] [13096] Setting option 'time.synchronize.tools.startup' to '1'.
[2026-01-08T17:56:41.436Z] [   debug] [vmtoolsd] [13096] Setting option 'toolScripts.afterPowerOn' to '1'.
[2026-01-08T17:56:41.436Z] [   debug] [vmtoolsd] [13096] Setting option 'toolScripts.beforePowerOff' to '1'.
[2026-01-08T17:56:41.436Z] [   debug] [vmtoolsd] [13096] Setting option 'toolScripts.afterResume' to '1'.
[2026-01-08T17:56:41.436Z] [   debug] [vmtoolsd] [13096] Setting option 'toolScripts.beforeSuspend' to '1'.
[2026-01-08T17:56:41.436Z] [   debug] [vmtoolsd] [13096] Setting option 'time.synchronize.tools.slewCorrection' to '1'.
...
Takže s největší pravděpodobností je na ESXi špatně nastavený systémový čas a v noci dojde k nějakému eventu, který vynutí resync i když je "vypnutý". Dle dokumentace

Virtual machine occasionally synchronizes time with the host even if you do not turn on periodic time synchronization. To completely disable time synchronization, you must set some properties in the virtual machine configuration file.
Power off the virtual machine.
Open the configuration (.vmx) file of the virtual machine in a text editor.
Add lines for the time synchronization properties and set the properties to FALSE.
tools.syncTime = "FALSE"
time.synchronize.continue = "FALSE"
time.synchronize.restore = "FALSE"
time.synchronize.resume.disk = "FALSE"
time.synchronize.shrink = "FALSE"
time.synchronize.tools.startup = "FALSE"
Save and close the file.

Při restartu vmtoolshd procne ten time.synchronize.tools.startup. V noci procne třeba něco jinýho.

Takže mi z toho vychází, že je špatně buď systémový čas v ESXi, nebo zmiňovaný offset (minimálně) pro tuto virtuálku. Čekám až se mi ozve admin. Skoro bych tipnul, že se u nás na firmě zprovoznil server, nastavil se čas a pak na to roky nikdo nešáhnul, ntp nebylo zapnuto, no a čas vesele driftuje o tu 0.8 vteřinu denně (což mi ale přijde docela dost). Ale třeba se pletu.

9

Windows a jiné systémy / Re:Skok systémového času Windows

« Poslední příspěvek od Filip Jirsák (forum) kdy Dnes v 12:05:26 »

VMware si udržuje pro každého hosta stav RTC jako ofset k času hostitele.
Při startu hosta vezme RTC z hostitele, přičte ofset. Při zápisu do RTC si uloží jen ten ofset.
Každý host může mít jiné časové pásmo i úplně jiný čas.
Do VM configu jde přidat relativní čas k hostiteli rtc.diffFromUTC nebo absolutní čas rtc.startTime.

Díky, nevěděl jsem, že už tam tato možnost je. (Teď se ukáže, že „už“ je 20 let…)

_{Škoda, že tu není možnost jenom dát komentáři palec nahoru, bez dalšího okecávání.}

10

Windows a jiné systémy / Re:Skok systémového času Windows

« Poslední příspěvek od Marvin kdy Dnes v 10:49:12 »

nevím o tom, že by nějaká virtualizační technologie udržovala systémové hodiny pro každého hosta zvlášť.

VMware si udržuje pro každého hosta stav RTC jako ofset k času hostitele.
Při startu hosta vezme RTC z hostitele, přičte ofset. Při zápisu do RTC si uloží jen ten ofset.
Každý host může mít jiné časové pásmo i úplně jiný čas.
Do VM configu jde přidat relativní čas k hostiteli rtc.diffFromUTC nebo absolutní čas rtc.startTime.