Witam, po raz kolejny zamek padł, teraz nawet razem z ESP-01 (tasmota), która była zainstalowana, żeby mieć możliwość zresetować zamek, kiedy on się zawiesi. Teraz ja już nie wiem, jaki jeszcze workaround można wymyślić, żeby umożliwić dalsze wykorzystanie z tego hackerskiego urządzenia na arduino i hot-glue 
IMHO nadszedł czas pomyśleć o zamku v2.0. Więc chciałbym przedyskutować niektóre kwestie. Jak myślicie TOTP kody to dobre rozwiązanie do zamku? Czy warto pomyśleć o czymś innym (RFID etc.)? Co można byłoby zrobić, żeby zamek był niezawodny? Jakie byśmy mogli zaznaczyć wymagania do zamku 2.0?
Wg mnie zamek w dotychczasowej formie się sprawdzał. Jedyny wyjątek – to kwestia niezawodności; powinien być odporny na zbieranie zakłóceń przez połączoną z nim instalację.
Po pierwsze i najważniejsze: zasilanie. Separacja galwaniczna linii sterującej przekaźnikiem, oddzielne masy dla części mikrokontrolerowej i sterującej elektrozaczepem. Przynajmniej część “crashy” pojawiała się, gdy elektrozaczep był załączany lub wyłączany.
Co do interfejsu użytkownika, moim zdaniem kody TOTP się dobrze sprawują. Z kartami RFID byłby ten problem, że trzeba by się zabezpieczyć przed klonowaniem kart. Tutaj wolałbym od razu iść w stronę kart DESFire, ale z otwartymi bibliotekami dla mikrokontrolerów jest sroga bieda, więc nie wiem, czy by to dało się sensownie zintegrować z resztą systemu.
Dobrym pomysłem też byłaby możliwość integracji sterownika z np. serwerem LDAP (jeśli się go kiedyś dorobimy xd) w celu scentralizowanego zarządzania dostępem dla członków. Tutaj jednak będzie konieczny upgrade mikrokontrolera, by system był w stanie dźwignąć komunikację ze światem zewnętrznym.
Niezależnie od tego, co będzie się działo z częścią sprzętową, firmware trzeba będzie przepisać - obecna implementacja wygląda niestety zbyt chaotycznie, by dało się to sensownie rozwijać. Z tego co pamiętam, @d33tah wspominał, że gdzieś w kodzie jest możliwy przypadek, że następuje dzielenie przez zero, co raczej niezbyt dobrze się kończy…
3 polubienia
@c3c7e0444f ile wiadomo o awarii? Czy spaliła się tylko Tasmota, czy Arduino też? Zastanawiam się jak trudno będzie przywrócić działanie zamka.
Nie wiem ile to roboty z tą separacją galwaniczną, ale pomysł wydaje mi się bardzo dobry.
Co do UX, chętnie zostałbym przy TOTP, bo moim zdaniem sprawdzały się nieźle.
Od strony kodu, na razie nie zwiększałbym scope rzeczami takimi jak LDAP, bo w pierwszej kolejności potrzebujemy zadbać o to żeby przywrócić możliwość przychodzenia bez klucza.
Prawdopodobnie w zamku zegar się zdesynchronizował, co się stało z ESP01 - nie wiem.
Co do wersji 2.0, to widzę takie wymagania:
- niezawodność
- łatwa obsługa (aktualizacja zegara, możliwość wymiany zamiast naprawy, tzn. przynajmniej jedno zapasowe urządzenie)
- płytka drukowana zamiast ‘Cthulhu z przewodów’ (wiem, że nie jest to po hakersku, ale)
- ekranowanie (płytki, przewodów + filtry od zakłóceń)
1 polubienie
Rozmawialiśmy z @c3c7e0444f na privie i przyszły nam do głowy takie usprawnienia:
- zamek powinien dać jakiś sygnał (np. SOS) jeśli kod TOTP rozjeżdża się z zegarem o ponad 30s,
- stan zegara możnaby zrobić publiczny - nie jest to informacja z założenia tajna, a jej brak utrudnia diagnostykę,
- aktualizacja zegara mogłaby być autoryzowana HOTP (TOTP nie zadziała jeśli zegar odjedzie, więc nie ma jak “zalogować” się jako admin)
Tutaj link do powiązanego fragmentu kodu:
https://github.com/hakierspejs/hsldz_totp_lock/blob/main/hsldz_totp_lock/hsldz_totp_lock.ino#L312
Wymagany login po github.