Witam wszystkich,
Zostałem tu skierowany przez właściciela projektu OpenBeken po tym, jak otworzyłem dyskusję na GitHubie dotyczącą inteligentnej wtyczki, której usługa w chmurze ma zostać wyłączona.
Krótkie wprowadzenie: producent zgodził się na rozmowy i obecnie analizuje wewnętrznie, jaką dokumentację techniczną może udostępnić społeczności open source. Firma stara się ustalić, jakie informacje można udostępnić bez ujawniania zastrzeżonego know-how, dlatego chciałbym przygotować praktyczną i realistyczną listę próśb. Na razie nic nie zostało zatwierdzone do publicznego udostępnienia, więc na tym etapie nie mogę publikować nazw marek/modeli ani zdjęć.
Aby jasno określić zakres: nie proszę o kod źródłowy oprogramowania układowego, szczegóły API chmury, zastrzeżone protokoły ani nic, co podlega tajemnicy handlowej. Celem są wyłącznie minimalne informacje na poziomie interfejsów, niezbędne do umożliwienia lokalnego sterowania za pomocą projektów takich jak OpenBeken czy ESPHome – te same informacje, które normalnie uzyskano by poprzez rozmontowanie urządzenia, z tą różnicą, że zostałyby one dostarczone bezpośrednio i dokładnie przez osoby, które zaprojektowały płytkę.
W tym miejscu liczę na waszą pomoc. Ponieważ firma udostępni jedynie ograniczony zestaw dokumentów, chcę, aby lista próśb została odpowiednio uszeregowana pod względem priorytetów. Mój obecny projekt:
Nazwa modelu mikrokontrolera / modułu Wi-Fi (rozumiem, że jest to najważniejsza pozycja)
Rozmieszczenie pinów UART i lokalizacja punktów testowych (TX, RX, 3,3 V, GND, pin boot/CEN)
Tabela mapowania GPIO (przekaźnik, przycisk, dioda LED stanu)
Model układu scalonego do pomiaru mocy (BL0937/BL0942/itp.) oraz jego piny interfejsu do mikrokontrolera
Czy włączona jest ochrona przed odczytem pamięci flash lub czy oprogramowanie układowe jest podpisane, ponieważ może to wpłynąć na to, o które informacje techniczne warto poprosić w pierwszej kolejności
Jeśli w projekcie wykorzystano dodatkowy mikrokontroler (np. mikrokontroler typu Tuya obsługujący przyciski/przekaźnik, podczas gdy układ Wi-Fi pełni rolę mostka szeregowego), dokumentacja protokołu szeregowego między mikrokontrolerami
Pytania do osób, które już to robiły:
- Czy powyższa kolejność priorytetów jest prawidłowa, czy też zmienilibyście ją?
- Czy pominąłem jakieś elementy, których dostarczenie jest dla producenta niedrogie, ale które są cenne przy portowaniu? (np. mapa partycji, metoda uruchamiania bootloadera, oryginalny plik binarny oprogramowania układowego, o ile można go legalnie udostępnić)
- W przypadku dwóch mikrokontrolerów: czy opis protokołu szeregowego na poziomie rejestrów/poleceń jest wystarczający, czy w praktyce potrzebne są również informacje dotyczące synchronizacji?
Jeśli współpraca dojdzie do skutku, opublikuję tutaj wyniki, udokumentuję wszystko, co producent wyraźnie zatwierdzi do publicznego ujawnienia, oraz udostępnię zdjęcia z demontażu i utworzę osobny wątek poświęcony konkretnemu chipsetowi. Podsumuję również, które informacje przekazane przez producenta okazały się najbardziej przydatne, aby to doświadczenie mogło pomóc w podobnych projektach w przyszłości.
Z góry dziękuję.
Będę wdzięczny za wszelkie rady od osób, które pracowały nad projektami OpenBeken, ESPHome, Tasmota lub podobnymi projektami związanymi ze sterowaniem lokalnym.
Zostałem tu skierowany przez właściciela projektu OpenBeken po tym, jak otworzyłem dyskusję na GitHubie dotyczącą inteligentnej wtyczki, której usługa w chmurze ma zostać wyłączona.
Krótkie wprowadzenie: producent zgodził się na rozmowy i obecnie analizuje wewnętrznie, jaką dokumentację techniczną może udostępnić społeczności open source. Firma stara się ustalić, jakie informacje można udostępnić bez ujawniania zastrzeżonego know-how, dlatego chciałbym przygotować praktyczną i realistyczną listę próśb. Na razie nic nie zostało zatwierdzone do publicznego udostępnienia, więc na tym etapie nie mogę publikować nazw marek/modeli ani zdjęć.
Aby jasno określić zakres: nie proszę o kod źródłowy oprogramowania układowego, szczegóły API chmury, zastrzeżone protokoły ani nic, co podlega tajemnicy handlowej. Celem są wyłącznie minimalne informacje na poziomie interfejsów, niezbędne do umożliwienia lokalnego sterowania za pomocą projektów takich jak OpenBeken czy ESPHome – te same informacje, które normalnie uzyskano by poprzez rozmontowanie urządzenia, z tą różnicą, że zostałyby one dostarczone bezpośrednio i dokładnie przez osoby, które zaprojektowały płytkę.
W tym miejscu liczę na waszą pomoc. Ponieważ firma udostępni jedynie ograniczony zestaw dokumentów, chcę, aby lista próśb została odpowiednio uszeregowana pod względem priorytetów. Mój obecny projekt:
Nazwa modelu mikrokontrolera / modułu Wi-Fi (rozumiem, że jest to najważniejsza pozycja)
Rozmieszczenie pinów UART i lokalizacja punktów testowych (TX, RX, 3,3 V, GND, pin boot/CEN)
Tabela mapowania GPIO (przekaźnik, przycisk, dioda LED stanu)
Model układu scalonego do pomiaru mocy (BL0937/BL0942/itp.) oraz jego piny interfejsu do mikrokontrolera
Czy włączona jest ochrona przed odczytem pamięci flash lub czy oprogramowanie układowe jest podpisane, ponieważ może to wpłynąć na to, o które informacje techniczne warto poprosić w pierwszej kolejności
Jeśli w projekcie wykorzystano dodatkowy mikrokontroler (np. mikrokontroler typu Tuya obsługujący przyciski/przekaźnik, podczas gdy układ Wi-Fi pełni rolę mostka szeregowego), dokumentacja protokołu szeregowego między mikrokontrolerami
Pytania do osób, które już to robiły:
- Czy powyższa kolejność priorytetów jest prawidłowa, czy też zmienilibyście ją?
- Czy pominąłem jakieś elementy, których dostarczenie jest dla producenta niedrogie, ale które są cenne przy portowaniu? (np. mapa partycji, metoda uruchamiania bootloadera, oryginalny plik binarny oprogramowania układowego, o ile można go legalnie udostępnić)
- W przypadku dwóch mikrokontrolerów: czy opis protokołu szeregowego na poziomie rejestrów/poleceń jest wystarczający, czy w praktyce potrzebne są również informacje dotyczące synchronizacji?
Jeśli współpraca dojdzie do skutku, opublikuję tutaj wyniki, udokumentuję wszystko, co producent wyraźnie zatwierdzi do publicznego ujawnienia, oraz udostępnię zdjęcia z demontażu i utworzę osobny wątek poświęcony konkretnemu chipsetowi. Podsumuję również, które informacje przekazane przez producenta okazały się najbardziej przydatne, aby to doświadczenie mogło pomóc w podobnych projektach w przyszłości.
Z góry dziękuję.
Będę wdzięczny za wszelkie rady od osób, które pracowały nad projektami OpenBeken, ESPHome, Tasmota lub podobnymi projektami związanymi ze sterowaniem lokalnym.
