Nevím jak to myslíš že to má OK, ale vzhledem k tomu že ten sensor má významy těch bitů definovaný trochu jinak než jsme zvyklí z DS18B20, tak by ten kód asi měl ještě upravit.
Jde o to, že bude muset měřit délky pulsů toho signálu z čidla, protože jednak jsou významy dle datasheetu takové, že krátká log.1 = významově „databit je v nule” a dlouhá log.1 = „databit je v jedničce”, a druhak každý to čidlo může mít v rámci nějakých výrobních odchylek tu komunikaci různě rychlou, takže z toho plyne, že nějaký __delay_ms(35); apod napevno v tom kódu v podstatě nemá co dělat, protože i kdyby to náhodou nějak na tomhle čidle rozchodil, tak po jeho výměně se mu ta komunikace stejně zase rozsype. Navíc z toho datagramu jde vidět, že to ani nedočetl do konce (po 16 pulsech mu to přestalo togglovat - dobře, beru, asi ho teplota nezajímá, ale: 1. na konci tý komunikace je nějakej checksum 2. nevím jak čidlo reaguje na přerušení komunikace, podle toho datagramu to vypadá že si vysílá vesele dál, na což je případně potřeba myslet před zahájením dalšího čtení).
Algoritmus čtení z čidla je v mbed knihovně kterou jsem sem už linkoval, a to i včetně měření délky pulsů. Je to v podstatě nejjednodušší způsob jak to udělat (je to jen pár podmínek), nevím proč si to z toho nechce vzít a radši se moří s něčím, co z principu fungovat nebude. Další možnej způsob by byl že by si to pokaždý odměřil např. čítačem/časovačem (když píšu „odměřil” tak myslím hardwarově, takže žádný delay), ale to by musel přepojit vstupy a použít CCP modul.