A nie masz innej płytki? Coś mi się zdaje że to AI halucynuje może by tak przeczytać dokumentację komponentu
Nie mam czasu aby teraz to sprawdzać, ale wklej to są AI jest to kod z komponentu Szczepana, ale piny raczej są takie same:
import logging
import esphome.config_validation as cv
from esphome.const import CONF_INPUT, CONF_MODE, CONF_NUMBER
from esphome.pins import check_strapping_pin
_ESP_32S3_SPI_PSRAM_PINS = {
26: "SPICS1",
27: "SPIHD",
28: "SPIWP",
29: "SPICS0",
30: "SPICLK",
31: "SPIQ",
32: "SPID",
}
_ESP_32_ESP32_S3R8_PSRAM_PINS = {
33: "SPIIO4",
34: "SPIIO5",
35: "SPIIO6",
36: "SPIIO7",
37: "SPIDQS",
}
_ESP_32S3_STRAPPING_PINS = {0, 3, 45, 46}
_LOGGER = logging.getLogger(__name__)
def esp32_s3_validate_gpio_pin(value):
if value < 0 or value > 48:
raise cv.Invalid(f"Invalid pin number: {value} (must be 0-46)")
if value in _ESP_32S3_SPI_PSRAM_PINS:
raise cv.Invalid(
f"This pin cannot be used on ESP32-S3s and is already used by the SPI/PSRAM interface(function: {_ESP_32S3_SPI_PSRAM_PINS[value]})"
)
if value in _ESP_32_ESP32_S3R8_PSRAM_PINS:
_LOGGER.warning(
"GPIO%d is used by the PSRAM interface on ESP32-S3R8 / ESP32-S3R8V and should be avoided on these models",
value,
)
if value in (22, 23, 24, 25):
# These pins are not exposed in GPIO mux (reason unknown)
# but they're missing from IO_MUX list in datasheet
raise cv.Invalid(f"The pin GPIO{value} is not usable on ESP32-S3s.")
return value
def esp32_s3_validate_supports(value):
num = value[CONF_NUMBER]
mode = value[CONF_MODE]
is_input = mode[CONF_INPUT]
if num < 0 or num > 48:
raise cv.Invalid(f"Invalid pin number: {num} (must be 0-46)")
if is_input:
# All ESP32 pins support input mode
pass
check_strapping_pin(value, _ESP_32S3_STRAPPING_PINS, _LOGGER)
return value
Ale ja w wersji 4 nie widzę wogule dla s3 żadnego kodu. Ja bym spróbował zmienić na inną plytkę.
Panowie szkoda czasu i nerwów.
Powiedzcie prosze jaka płytkę kupic aby to działało.
Najlepiej bezpośredni link do ali.
Co jeszcze chciałbym podpiąć to 3-4 czujniki temperatury DS18B20.
Witam ponownie
Są pewnie postępy mianowicie :
Wywaliłem płytkę : esp32 s3 n16r8
Próbowałem na esp32 s3 super mini ale tu się okazało ze niby ma 4mega ale podzielone na 2 partycje , próbowałem to połączyć ale nie wyszło.
W końcu znalazłem stare esp8266 nodemcu v3 i dopiero na tym sprzęcie udało się odczytać ramki z licznika .
Odczytałem swoją ramkę , niestety potrzebuję klucza , a mój zarządca nie chce mi go udostępnić zasłaniając się bezpieczeństwem , rodo itd .
Notabene na apator162 ramka dekoduje się na kluczu same zera .
Czyli teraz mam pewność że moje sprzęty działają .
Pismo z wodociągów :
W odpowiedzi na zapytanie Pana dotyczące przekazania klucza szyfrującego
do zainstalowanych nakładek wodomierzowych,
stanowisko Spółki jako dysponenta przypisanych zasobów jest następujące.
Przekazywanie kluczy szyfrujących niesie ryzyko bezpieczeństwa danych,
a mianowicie przekazanie kluczy otwiera dostęp do surowych danych o zużyciu wody,
co w świetle obowiązujących przepisów o ochronie danych może nieść za sobą ryzyko
naruszenia prywatności użytkowników końcowych.
Ponadto nieautoryzowany dostęp do transmisji danych może narazić
strukturę odczytową na próby manipulacji lub zakłócenia,
za które Spółka nie może ponosić odpowiedzialności.
Raz przekazane klucze wychodzą poza kontrolowane środowisko zabezpieczeń producenta.
Nie mamy możliwości monitorowania, w jaki sposób i przez kogo są one dalej przetwarzane.
Spółka w trosce o bezpieczeństwo danych naszych klientów i kontrahentów
oraz zachowując najwyższe standardy bezpieczeństwa przy transferze danych
nie wyraża zgody na udostępnienie klucza szyfrującego nakładkę wodomierzową.```
No i widzisz sam jak bezczelnie kłamią - klucz fabryczny same zera (powszechnie stosowany w modelu AT-WMBUS-16-2), natomiast jeśli chodzi o RODO, to od ręki przegrywają w UODO, bo takie tłumaczenia są całkowicie sprzeczne z ideą RODO.
Wysmarowali stek bzdur, niestety taki przywilej monopolu, jeśli ktokolwiek mógłby tu pomóc to może UOKiK? Niestety rynek wody jest oparty na monopolu.
Aby było weselej nawet potencjalne oszukiwanie na odczytach nie jest możliwe, bo stan fizycznego licznika jest sprawdzany zarówno przy jego wymianie jak i podejrzeniach manipulacji.
Zgodnie z RODO dane o dobowym/godzinowym zużyciu wody przez osobę fizyczną stanowią dane osobowe. Jako podmiot tych danych, masz ustawowe prawo do dostępu do nich w formie zrozumiałej (Art. 15 RODO). Odmawiając klucza, uniemożliwiają realizację prawa do monitorowania własnych danych w czasie rzeczywistym. Twierdzenie, że udostępnienie danych o sobie samym narusza prywatność, jest logicznym absurdem.
Apator 16-2 pracują w trybie jednokierunkowym. Odczyt ramki radiowej jest procesem pasywnym. Posiadanie klucza deszyfrującego nie daje żadnej technicznej możliwości „manipulacji” urządzeniem czy „zakłócenia” sieci, ponieważ odbiornik nie wysyła żadnych sygnałów do urządzenia – on jedynie słucha.
Jakbyś im takie coś wystosował to raczej by się przekonali. Ale, po co jak klucz to same zera
ODWOŁANIE OD DECYZJI ORAZ WEZWANIE DO UDOSTĘPNIENIA DANYCH
W nawiązaniu do otrzymanego pisma , w którym odmówiono mi udostępnienia klucza AES do nakładki wodomierzowej, niniejszym składam odwołanie i wnoszę o ponowne rozpatrzenie mojej prośby.
Uzasadnienie przedstawione przez Spółkę opiera się na błędnych przesłankach technicznych i prawnych, co wykazuję poniżej:
1. Naruszenie prawa do dostępu do własnych danych osobowych (RODO) Zgodnie z Art. 15 Rozporządzenia RODO, jako osoba, której dane dotyczą, mam prawo do uzyskania od administratora dostępu do moich danych osobowych. Informacje o zużyciu wody w moim gospodarstwie domowym, powiązane z moim adresem i umową, stanowią moje dane osobowe. Zgodnie z Art. 20 RODO (Prawo do przenoszenia danych), mam prawo otrzymać te dane w formacie nadającym się do odczytu maszynowego. Klucz AES jest niezbędnym narzędziem technicznym (cyfrowym odpowiednikiem klucza do drzwi), bez którego dostęp do moich danych w czasie rzeczywistym jest niemożliwy.
2. Brak zagrożenia dla infrastruktury odczytowej Argumentacja dotycząca „narażenia struktury odczytowej na manipulację” jest bezzasadna. Odczyt, który zamierzam prowadzić, ma charakter całkowicie pasywny. Moje urządzenie pełni jedynie rolę odbiornika sygnału radiowego, który nakładka i tak emituje w przestrzeń publiczną. Odbiór sygnału nie wiąże się z wysyłaniem jakichkolwiek komend do urządzenia, nie ingeruje w jego pracę, nie skraca czasu życia baterii ani nie blokuje odczytów prowadzonych przez Spółkę. Technologia AES-128 służy do zachowania poufności transmisji, a nie do sterowania urządzeniem.
3. Zgodność z Dyrektywą EED (2018/2002) Zwracam uwagę, że unijne przepisy (Dyrektywa o efektywności energetycznej) kładą coraz większy nacisk na prawo konsumenta do bieżącego monitorowania zużycia mediów. Blokowanie dostępu do tych danych stoi w sprzeczności z ideą budowania świadomości ekologicznej i optymalizacji zasobów wodnych.
4. Bezpieczeństwo danych Spółka twierdzi, że przekazanie klucza niesie ryzyko naruszenia prywatności. Podkreślam, że klucz ma dotyczyć wyłącznie mojego licznika. Przekazanie mi klucza do danych, których sam jestem właścicielem i podmiotem, nie stanowi naruszenia prywatności osób trzecich ani bezpieczeństwa sieci.
W podsumowaniu: Podtrzymuję prośbę o udostępnienie klucza AES. Jednocześnie informuję, że w przypadku ponownej odmowy, będę zmuszony skierować sprawę do Prezesa Urzędu Ochrony Danych Osobowych (UODO) z prośbą o interwencję w zakresie uniemożliwienia mi dostępu do własnych danych osobowych w formacie nadającym się do odczytu maszynowego.
Próbowałem też na LILYGO ® TTGO LoRa32 V2.1_1.6, ale utknąłem na:
```
[19:45:39][V][mdns:133]: TXT: version = 2025.8.0
[19:45:39][D][sntp:065]: Synchronized time: 2026-03-04 19:39:34
[19:46:36][D][packet:097]: Have data from radio (8 bytes)
[19:46:36][D][wmbusmeters:351]: raw packet "844B8C7A05CFE9AC"
[19:46:36][V][packet:073]: expected_size: 8
[19:46:36][V][wmbusmeters:4841]: (wmbus) not enough bytes! expected at least 12 but got (8)!
[19:46:36][V][packet:073][radio_recv]: expected_size: 8
