2026-03-11

Zkušenosti s asistenční službou UAMK pro motorku

Na začátku každé motorkářské sezóny se někdo zeptá, jestli si má pořídit k motocyklu doplňkové asistenční služby / pojištění. Já jsem je párkrát vyzkoušel (ač jsem po tom netoužil) a přináším shrnutí mé zkušenosti pro ostatní. Tato "pojistka" není pro zázraky, ale spíš jako poslední instance řešení nepojízdného stroje. 

Volal UAMK dvakrát s motorkou v zahraničí (tarif 1890 Evropa KK031). Jednou hřebík v pneu uprostřed ničeho v neděli odpoledne a podruhé elektrika vyhazovala pojistku taky ve strašné díře. Pokaždé se mi během nekonečných hovorů s nimi podařilo vyřešit problém po svém zastavením nějaké okolo jedoucí dodávky nebo zavoláním kamarádům kamarádů.


V rámci výběru asistenčky bych jim zkusil o víkendu v sezóně zavolat. Už jenom jak dlouho trvá než se dostane na řadu. Druhá věc je, že stejně to český operátor předává místní službě (podstata všech asistenček) takže je zřejmě jedno u koho to je, protože se stejně čeká reakci domorodých odtahovek.

Co je dobré vědět: Ta paní na asistenčce není mechanik - sedí nad mapou a nějakým seznamem servisů. Ten člověk co sedí v odtahovce taky není mechanik. Většinou oba umí dobře řešit auta, motorky jsou pro ně zjevně složitější. Pointa je, že vás dostanou do místa, kde bude v běžné pracovní době někdo v servisu. Je potřeba od systému asistenčky nečekat zázraky (jako rychlou opravu na místě).

Co mi pomohlo je vědět kam se chci dostat a říct si o to. Odtahovka se zadává do systému jako bod A a bod B. Dokud to nemáte ztrácíte čas. Ideálně si sám vygooglit kde je nějaký akceptovatelný moto servis s hotelem poblíž. Nejšťastnější všichni budou, když se vám závada stane na dálnici.


Vždycky to trvalo tak 2,5 hodiny než se od mého volání ozval někdo z místního autoklubu, že se chystá sednout do auta a vyjet ke mně. Je fajn mít vodu a nabitý telefon (pozor na to u bezdrátové navigace). Lidem co mi reálně pomohli jsem platil cash, takže je fajn nějaké peníze mít i když se dá dneska na 99 % cestovat po Evropě jen na bankovní kartu (vlastně i po USA).

Nebyl jsem si jistý, že jsem chtěl s UAMK pokračovat, ale nakonec jsem to opět prodloužil. Nejvíc mi jejich služba dává smysl kdybych naboural a zbytek výletu byl ztracený tak jako tak. Nejlepší je nezanedbat údržbu a mít to cestovatelské štěstíčko.

Ještě později jsem volal pomoc k vybité baterce v městečku v Anglii: trvalo to 1,5 hodinky než přijel týpek od The AA s jump startem a nahodili jsme stroj. To bylo vlastně jedinkrát, kdy jsem službu opravdu využil.


I přes nepříliš veselé zkušenosti si ÚAMK platím dále (už je to skoro 10 let!). Zřídil jsem si ji se slevou od České Pošty ke které se později přidal bonus za věrnost. 

Mám režim "pro majitele", takže se pomoc vztahuje na jakékoliv vozidlo které řídím a to i těch se zahraniční registrací. Číslo karty ÚAMK zajímá operátora jako první, ale fyzicky kartičku nechtěl nikdo vidět.

Nezapomeňte, že jako každé připojištění vám proplatí výdaje až zpětně. Pečlivě si prostudujte limity a podmínky: je to sice levné, ale zase to moc nekryje. 

Prvně publikováno na fóru Motorkari.cz

Disclaimer: asi bych volal pomoc méně, kdybych nejezdil na indické Jawě, na druhou stranu mi lidé na cestách pomáhali o to ochotněji s tímto krásným strojem.

2026-02-10

Business Central načasování aktualizací

Při plánování aktualizací pro Dynamics 365 Business Central (online) administrátoři jako já často narazí na rozdíl mezi datem naplánované aktualizace v e-mailech, v datu zobrazeném v BC Admin Center a z notifikace o provedené aktualizace. To může být matoucí – zejména pokud se rozdíl zdá být celý jeden den. 

Všechna nastavení okna pro aktualizaci v Centru pro správu jsou v místním čase. Administrátoři mohou nastavit:

  • Naplánované datum aktualizace.

  • Čas začátku a konce okna pro aktualizaci (v místním časovém pásmu). 

Business Central interně převádí místní čas pro aktualizaci do UTC zóny. 

Dokumentace Microsoftu uvádí:

  • Okno pro aktualizaci se zadává v místním čase.

  • Systém však vyhodnocuje a spouští aktualizaci pomocí UTC.

  • To znamená, že plánovač používá verzi okna převedenou na UTC, i když vy v portálu vidíte místní čas.

Business Central spustí aktualizaci, jakmile jsou splněny obě tyto podmínky:

  1. V čase UTC nastalo naplánované datum.

  2. Aktuální čas UTC spadá do okna pro aktualizaci převedeného na UTC.

Neexistuje žádné pravidlo, které by říkalo, že BC čeká na místní kalendářní datum. Relevantní hranicí je půlnoc UTC, nikoliv místní půlnoc.

Proč uživatelé někdy vidí aktualizace běžet lokálně „dříve“?

Protože se datum i okno pro aktualizaci vyhodnocují v UTC, může aktualizace začít dříve, než začne místní naplánované datum, pokud:

  • Naplánované datum v UTC nastalo dříve než v místním čase.

  • Převedené okno v UTC se překrývá s předchozím místním dnem.

Toto není chyba – je to přímý důsledek plánovací logiky. Typický příklad jsou americké časové zóny pro evropské uživatele.

Příklad 1

  • Naplánované datum (místní): 14. února 
  • Okno (místní): 00:00–06:00
  • Místní časové pásmo: UTC+02
    •  
    • 06:00 na 04:00 UTC (stejný den)

Tudíž okno v UTC je: 22:00 UTC 13. února 04:00 UTC 14. února

Kdy může BC začít? Jakmile nastane v UTC 14. února, což se stane ve 02:00 místního času (UTC+02), a zároveň je čas UTC uvnitř převedeného okna. Protože se okno v UTC otevírá už ve 22:00 UTC předchozího dne, může se to překrývat s předchozím místním večerem.

Příklad 2

  • Naplánované datum aktualizace: 24. září
  • Okno pro aktualizaci (místní CST, UTC-6): 21:00 → 04:00 
  • Převod okna na UTC:
    • 21:00 CST = 03:00 UTC (následující den) 
    • 04:00 CST=10:00 UTC (stejný​ den)

Tudíž okno v UTC je: 03:00 10:00 UTC dne 25. září

Kdy BC uvidí naplánované datum? Naplánované datum 24. září v UTC nastane mnohem dříve, než nastane 24. září v CST.

Kdy BC spustí aktualizaci? V první moment, kdy jsou obě podmínky pravdivé:

  1. Datum UTC 24. září.
  2. Aktuální čas UTC je mezi 03:00 a 10:00 UTC (25. září UTC).

Protože 03:00 UTC dne 25. září odpovídá 22:00 CST dne 23. září, BC zcela legitimně zahájí aktualizaci: 23. září ve 22:19 CST.

Není to brzy – je to správně podle:

  • Začátku data UTC.
  • Okna převedeného na UTC.

2026-02-02

Cybex Isofix demontáž sedačky

Zacvaknutí dětské sedačky (Cybex Aton 5 base 2 fix) s isofixem je snadné a je na to spousta návodů na Youtube, ale jak ji pak vytáhnout? Než získáte potřebnou zkušenost, tak se sytém zdá být záhadný. 

Správná odpověď je

Pro vycvaknutí paciček musíte nejprve zatlačit dětskou sedačku ještě více do sedadla a přitom zmáčknou plastovou šedou západku (s těmi barevnými indikátory) na boku kolejniček, tím se úchopový mechanismus uvolní a pustí se. Je možné dělat každou stranu zvlášť.

Snad vám to pomůže, protože není větší legrace než se snažit naložit moknoucí pasažéry do auta, kde zrovna překáží "zaseknutá " základna dětské sedačky, zatímco vám prší na záda.

2026-01-01

Azure Performance Diagnostics Extension deployment failed

I got the following error when deploying AzPerfDiagExtension via Azure Portal

"VMExtensionProvisioningError", "message": "VM has reported a failure when processing extension 'AzurePerformanceDiagnostics' (publisher 'Microsoft.Azure.Performance.Diagnostics' and type 'AzurePerformanceDiagnostics'). Error message: 'Failed to enable extension 'AzPerfDiagExtension' because either the storage account name or key provided is invalid. Please re-install extension 'AzPerfDiagExtension' using a valid storage account name and key or install Performance Diagnostics by navigating to the VM -> Help -> Performance Diagnostics blade.'. More information on troubleshooting is available at https://aka.ms/vmextensionwindowstroubleshoot. "

There are two blades how to initiate PerfDiag installation. One is to add an extension to the VM, and the second is to scroll down to the independent tab "Performance Diagnostics" in the Help column of the virtual machine.

It offers to use storage keys and managed identity. I could list SAK so I expected at least this option working but it wasn't. My role was "only" contributor so I was expecting an error coming from some permission issue.

Here are the permissions needed listed to Run Performance Diagnostics.

  • The Owner role on the VM and an Azure role that includes the Microsoft.Storage/storageAccounts/listkeys/action permission on the storage account

I requested owner role for VM and I got it. The issue is that I am owner for my user account, but that isn't affecting relation between the VM and the storage account. What I did to fix the problem is to assign permissions of owner" (actually somehting less should be better) for the managed identity of the VM via IAM configuration.


Once again I granted permissions via IAM to storage account for the managed identity of the VM, not for myself as user. It wasn't obvious to me that it is needed like this and I spent some time trying to figure out what it was.








What is interesting on this solution is that I previously tried to configure performance diagnostic with manual storage account name and SAK insertion to the Azure portal installation wizard (for VM Extension installation) but it failed as many time before.

What was tried (before granting permission for SA to managed identity of the VM)

  1. Copied fresh keys from the Storage account “Access keys” blade and manually pasted into the extension protected settings (not using connection strings).
  2. Explicitly set authenticationType: StorageKey.
  3. Confirmed account name syntax (lowercase, alphanumeric).
  4. Verified region match (VM and storage in same Azure region).
  5. Ensured network access (public “All networks”).
  6. Retried installation through both Support + troubleshooting → Performance diagnostics blade and extension install path.

The error might have more verbose version from Performance diagnostic blade

Failed to retrieve storage account information for performance diagnostics. Try reinstalling performance diagnostics. Error details: {"name":"StorageError","message":"Server failed to authenticate the request. Make sure the value of Authorization header is formed correctly including the signature.\n
"xhr":{"status":403,"statusText":"Server failed to authenticate the request. Make sure the value of Authorization header is formed correctly including the signature.","responseText":"{\"odata.error\":{\"code\":\"AuthenticationFailed\",\"message\":{\"lang\":\"en-US\",\"value\":\"Server failed to authenticate the request. Make sure the value of Authorization header is formed correctly including the signature.\"}}}"}}} {"name":"StorageError","message":"The table specified does not exist\n
"status":404,"statusText":"Not Found","responseText":"{\"odata.error\":{\"code\":\"TableNotFound\",\"message\":{\"lang\":\"en-US\",\"value\":\"The table specified does not exist.\"}}}"}}}

2025-12-28

Dětská lahvička zežloutla v myčce

Nedávno se mi stalo něco nečekaného s kojeneckou lahvičkou Philips Avent. Mám ji asi měsíc a po nějaké době jsem ji dal opět do myčky, stejně jako předtím (obvykle ji vyplachuji / vyvařuji / myju ručně) na eco program. Tentokrát ale z myčky vyšla žlutá až oranžová. A nejen samotná lahev. Stejně zbarvený byl i silikonový cucák a neprůhledná závitová část. Na první pohled to vypadalo jako obarvení od jídla, ale to jsem rychle vyloučil. Výsledek byl stejný i po druhém cyklu. Internet tvrdí, že silikon se kari nebo rajčaty nezbarví. Tady bylo něco jinak.

Tento článek je napsán AI jako shrnutí mých dotazů při diagnostice popsaného problému. Není ověřen, ale mi se vysvětlení zdá dostatečné věrohodné. Příčina ve zkratce: levné tablety do myčky

Když jsem si lahev prohlížel, všiml jsem si, že zbarvení je stejné na třech různých materiálech. To je důležitý signál. Plast, silikon a polyethylenové nebo polyamidové díly reagují na jídlo různě. To ukazuje na chemickou reakci, ne na špínu. Další zajímavost byla, že barva vypadala jinak podle typu světla. V žárovkovém světle byla spíš žlutá, pod LED páskem světle oranžová. Jiný lom světla je typický pro změnu povrchu materiálu.

Zkusil jsem ji dát znovu do myčky se stejnou kapslí beze změny, taktéž umýt ručně, vyvařit, použít citronovou šťávu. Musí tedy jít o chemické zabarvení způsobené mycím prostředkem. A pak mi to došlo: Dříve jsem používal značkové Finish kapsle (z Lidlu), které takový problém nezpůsobily. Tentokrát jsem měl W5 Platinum All‑in‑One z Lidlu. A tady je jádro věci. Tyhle kapsle jsou sice levnější a účinné, ale mají několik vlastností, které jsou pro plastové a silikonové výrobky rizikové. Mají silnější oxidační složku, agresivnější enzymy, optická zjasňovadla a syntetickou parfemaci „fresh“. Navíc se rozpouštějí rychle a prudce. Oba dva typy kapslí jsou tekuté v rozpustném sáčku. Přídavné levné tekuté leštidlo bylo v myčce Bosch nalité stejné, takže tím to nebylo (mám ho nastavené na minimum, protože by mělo být součástí té kapsle, ale bez něj to hlásí varování).

Výsledek je přesně to, co jsem viděl: povrch plastu se mikroskopicky naruší, silikon absorbuje stopové molekuly a optická zjasňovadla se navážou na povrch. Materiál pak začne jinak odrážet světlo a získá žlutý až oranžový nádech. Samotná barva není toxická, ale změna vzhledu znamená, že materiál byl chemicky ovlivněn. Povrch může být poréznější, může se rychleji degradovat a může uvolňovat více látek při zahřátí. U kojeneckých lahví se proto doporučuje výměna při jakékoli změně vzhledu.

Pokud se vám stane něco podobného, "není to vaše chyba". Doporučuje se používat šetrnější kapsle, dávat lahve do horního koše dál od dávkovače a vyhnout se intenzivním programům. A pokud lahev změní barvu, je lepší ji vyměnit.

Dejte mi vědět, pokud se to stalo i vám.