Działa poprawnie.
Sorki mój błąd
Poprawnie działające wpisy dla OneMeter pod E.on:
w configuration.yaml
# RESTful API
# https://www.home-assistant.io/integrations/api
rest:
- resource: https://cloud.onemeter.com/api/devices/<ID_MOJE_URZADZENIE>
scan_interval: 900
headers:
Authorization: <MOJE_API>
sensor:
- name: "E.on - Prognoza zużycia w miesiącu Ratio [kWh]"
unit_of_measurement: "kWh"
icon: mdi:flash
value_template: "{{ value_json.usage['projectionFillRatio'] }}"
- name: "E.on - Prognoza zużycia w miesiącu [kWh]"
unit_of_measurement: "kWh"
icon: mdi:flash
value_template: "{{ value_json.usage['projection'] }}"
- name: "E.on - Całkowite zużycie w kWh" #od poczatku instalacji licznika
unit_of_measurement: "kWh"
icon: mdi:flash
value_template: "{{ value_json.lastReading.OBIS['F_8_0'] }}"
- name: "OneMeter Voltage baterii"
unit_of_measurement: "v"
icon: mdi:battery
value_template: "{{ value_json.lastReading.OBIS['S_1_1_2'] }}"
- name: "E.on - ostatni odczyt"
icon: mdi:clock
value_template: "{{ value_json.lastReading.OBIS['S_1_1_4'] }}"
- name: "E.on - zużycie w bieżącym miesiącu"
unit_of_measurement: "kWh"
icon: mdi:calendar-month
value_template: "{{ value_json.usage['thisMonth'] }}"
- name: "E.on - zużycie w poprzednim miesiącu"
unit_of_measurement: "kWh"
icon: mdi:calendar-month-outline
value_template: "{{ value_json.usage['previousMonth'] }}"
- name: "OneMeter wersja firmware urządzenia"
icon: mdi:chip
value_template: "{{ value_json.firmware['currentVersion'] }}"
- name: "OneMeter Battery %"
unit_of_measurement: "%"
icon: mdi:battery
value_template: "{{ value_json.lastReading['BATTERY_PC'] }}"
- name: "E.on - całkowite zużycie" #od instalacji urządzenia
device_class: energy
state_class: total
unit_of_measurement: "kWh"
icon: mdi:home-lightning-bolt-outline
value_template: "{{ value_json.usage['fullTime'] }}"
- name: "E.on - zużycie w tym miesiącu" #od instalacji urządzenia
device_class: energy
state_class: total
unit_of_measurement: "kWh"
icon: mdi:home-lightning-bolt-outline
value_template: "{{ value_json.usage['thisMonth'] }}"
- name: "ID Urzadzenia"
icon: mdi:chip
value_template: "{{ value_json['id'] }}"
- name: "OneMeter SN Urządzenia"
icon: mdi:chip
value_template: "{{ value_json['SN'] }}"
- name: "Onemeter MAC Urządzenia"
icon: mdi:chip
value_template: "{{ value_json['MAC'] }}"
- name: "OneMeter MeterID"
icon: mdi:chip
value_template: "{{ value_json.meteringPoint['meterID'] }}"
- name: "E.on - taryfa"
icon: mdi:chip
value_template: "{{ value_json.config.contract.distributionTariff.distributionNetworkOperator.group['name'] }}"
utility_meter:
#Do OneMeter
hourly_energy:
source: sensor.e_on_calkowite_zuzycie
cycle: hourly
daily_energy:
source: sensor.e_on_calkowite_zuzycie
cycle: daily
weekly_energy:
source: sensor.e_on_calkowite_zuzycie
cycle: weekly
monthly_energy:
source: sensor.e_on_calkowite_zuzycie
cycle: monthly
yearly_energy:
source: sensor.e_on_calkowite_zuzycie
cycle: yearly
w ui-lovelace.yaml #Aby wyświetlać sensory
- cards:
- entities:
- sensor.hourly_energy
hour24: true
hours_to_show: 24
name: E.on - Energy Usage hourly
points_per_hour: 1
show:
graph: bar
type: 'custom:mini-graph-card'
- cards:
- entities:
- sensor.monthly_energy
name: E.on - Energy Usage montly
points_per_month: 1
show:
graph: bar
type: 'custom:mini-graph-card'
- cards:
- entities:
- entity: sensor.e_on_calkowite_zuzycie
- entity: sensor.e_on_zuzycie_w_poprzednim_miesiacu
- entity: sensor.e_on_zuzycie_w_biezacym_miesiacu
- entity: sensor.e_on_ostatni_odczyt
show_header_toggle: true
title: E.on - zuzycie
type: entities
- cards:
- entities:
- entity: sensor.hourly_energy
- entity: sensor.daily_energy
- entity: sensor.weekly_energy
- entity: sensor.monthly_energy
- entity: sensor.yearly_energy
show_header_toggle: true
title: OneMeter Energy Usage
type: entities
Najwazniejsze rzeczy dzialają. Część nie. Testuję.
UWAGA!!
Konfiguracja dla OneMeter - pod E.on {Innogy}
Dla innych dostawców możliwe zmiany.
Jakby co pytać
Ja jeszcze dodałbym do wpisu:
device_class: battery
co spowoduje wykrywanie przez kartę battery state card, że to jest bateria:
Dziękuję.
A czy ktoś pomoże z wyciągnięciem taryfy?
- name: "E.on - taryfa"
icon: mdi:chip
value_template: "{{ value_json.config.contract.distributionTariff.distributionNetworkOperator.group['name'] }}"
Możesz sprawdzić, w którym miejscu w tym adresie testowym.
https://cloud.onemeter.com/api/devices/<DEVICE_ID>?key=<API_KEY>
Tylko do tego nie używaj chrome, może być firefox lub edge - wynik jest podawany czytelnie i tam wtedy zobaczysz wszystkie odczyty i co musisz wpisać w nawiasach. U różnych operatorów różnie to wygląda, np. u mnie to:
value_template: "{{ value_json.lastReading.OBIS['0_2_2'] }}"
może też być, tak jak u Ciebie, tylko mniej:
value_template: "{{ value_json.config.contract.distributionTariff['name'] }}"
Ok. Dzięki. Działa.
Nie wiedziałem jak się do tego zabrać. Teraz zrozumiałem kod.
Zastanawiam się, czy nie dodać jeszcze jednej encji, która pokazuje stan mojego banku energii u operatora (mam jeszcze po staremu 
). Wydaje mi się, że parametr state_class: measurement będzie odpowiedni, bo wartości zmieniają się, mogą być dodatnie i ujemne, np. w dniu dzisiejszym mam -3400kWh
- name: "OneMeter Zapas Energii"
device_class: energy
state_class: measurement
unit_of_measurement: "kWh"
icon: mdi:home-battery
value_template: "{{ value_json.energyBankData.nextLoss['total'] }}"
Docelowo chciałbym dodać do Panelu Energia jako Domowy magazyn energii - myślicie, że będzie to działać?
If any of you have missed this piece of news regarding OneMeter:
wygląda na to że chmura padła. czy da się coś z tym zrobić np odczytywać dane lokalnie
A myślałem, że to u mnie coś nawaliło.
Kilka dni temu założyciel ogłosił w liście otwartym, że OneMeter wycofuje się z rynku.
Facebook
Cytuję poniżej Mateusza Brzozowskiego:
Przez lata walczyłem o demokratyzację dostępu do danych o zużyciu energii. Zbudowałem firmę OneMeter, która dawała Polakom narzędzie do świadomego zarządzania energią.
𝐍𝐢𝐞𝐬𝐭𝐞𝐭𝐲, 𝐝𝐞𝐜𝐲𝐳𝐣𝐞 𝐩𝐚ń𝐬𝐭𝐰𝐨𝐰𝐲𝐜𝐡 𝐦𝐨𝐧𝐨𝐩𝐨𝐥𝐢 𝐞𝐧𝐞𝐫𝐠𝐞𝐭𝐲𝐜𝐳𝐧𝐲𝐜𝐡 𝐬𝐩𝐫𝐚𝐰𝐢ł𝐲, ż𝐞 𝐏𝐨𝐥𝐚𝐜𝐲 𝐳𝐨𝐬𝐭𝐚𝐥𝐢 𝐩𝐨𝐳𝐛𝐚𝐰𝐢𝐞𝐧𝐢 𝐩𝐫𝐚𝐰𝐚 𝐝𝐨 𝐰ł𝐚𝐬𝐧𝐲𝐜𝐡 𝐝𝐚𝐧𝐲𝐜𝐡.
Po latach walki z systemem, ignorowania przez urzędy i dezinformacji, jestem zmuszony się poddać. Moja firma upadła, bo uniemożliwiono jej działanie na rynku.
W poniższym liście wyjaśniam, dlaczego tak się stało i kto jest za to odpowiedzialny. To nie jest tylko historia mojego upadku. To przestroga i wezwanie do działania dla nas wszystkich.
𝐏𝐫𝐨𝐬𝐳ę, 𝐩𝐫𝐳𝐞𝐜𝐳𝐲𝐭𝐚𝐣𝐜𝐢𝐞 𝐢 𝐩𝐨𝐝𝐚𝐣𝐜𝐢𝐞 𝐝𝐚𝐥𝐞𝐣. 𝐍𝐢𝐞 𝐩𝐨𝐳𝐰ó𝐥𝐦𝐲, 𝐛𝐲 𝐦𝐨𝐧𝐨𝐩𝐨𝐥 𝐧𝐚𝐝 𝐝𝐚𝐧𝐲𝐦𝐢 𝐳𝐝𝐮𝐬𝐢ł 𝐢𝐧𝐧𝐨𝐰𝐚𝐜𝐣𝐞 𝐢 𝐨𝐝𝐞𝐛𝐫𝐚ł 𝐧𝐚𝐦 𝐧𝐚𝐬𝐳𝐞 𝐩𝐫𝐚𝐰𝐚.
------
List do Klientów i Przyjaciół OneMeter
Drodzy Przyjaciele,
OneMeter stworzyłem z myślą o tym, by usprawnić najbardziej zacofany informatycznie obszar gospodarki — energetykę. Od dziecka miałem potrzebę naprawiania rzeczy, które nie działały tak, jak powinny.
Włożyłem w OneMeter całe serce, kilka lat pracy i wszystkie swoje środki. Zbudowałem zespół pełnych pasji młodych inżynierów, z którymi najpierw tworzyliśmy prototypy w pokojach Politechniki Warszawskiej, a potem — gotowe rozwiązanie w naszym biurze.
Nie było idealne, ale działało. Dzięki wsparciu z NCBR mogliśmy je rozwijać i udoskonalać.
Kiedy byliśmy gotowi, by wejść na rynek, okazało się jednak, że nasz produkt jest nie na rękę państwowym spółkom energetycznym i operatorom systemów dystrybucyjnych (OSD).
Dlaczego?
Bo demokratyzował dostęp do informacji — każdy odbiorca energii mógł wreszcie odczytywać cyfrowo dane o swoim zużyciu i świadomie nimi zarządzać.
Do tej pory było to zarezerwowane tylko dla operatorów z odpowiednim sprzętem.
W latach 2018–2020 OSD rozpoczęły działania zmierzające do zablokowania lokalnego dostępu do danych z liczników.
W efekcie wdrożono u prosumentów liczniki z zablokowanym portem optycznym — uniemożliwiając im korzystanie z takich rozwiązań jak OneMeter.
Nasza spółka, mimo ogromnych inwestycji i grantów, została praktycznie odcięta od rynku.
Podejmowaliśmy próby rozmów z OSD, Ministerstwem Energii, URE i UOKiK. Wszystkie — zostały zignorowane.
Zdarzały się nawet przypadki, gdy OSD mówiły klientom, że nasze rozwiązanie jest „nielegalne”.
Przyznaję — przez lata ta sytuacja wypaliła we mnie źródło energii.
Z osoby, która kochała tworzyć i naprawiać, stałem się kimś wypalonym, bez siły by dalej walczyć z systemem.
W lutym 2025, gdy przeczytałem komentarz: 𝐎𝐧𝐞𝐌𝐞𝐭𝐞𝐫 𝐭𝐨 ś𝐰𝐢𝐞𝐭𝐧𝐞 𝐫𝐨𝐳𝐰𝐢ą𝐳𝐚𝐧𝐢𝐞, coś we mnie pękło.
Wyłączyłem sprzedaż, zwróciłem środki za niezrealizowane zamówienia i odsunąłem się, by spróbować odzyskać równowagę.
Nie udało się.
Po prostu — nie mam już siły dźwigać tego ciężaru sam, więc dzielę się nim z Wami, by mógł stać się początkiem zmiany.
Dziękuję wszystkim, którzy wierzyli w OneMeter — klientom, wspólnikom, inżynierom, przyjaciołom.
Bez Was nie zaszlibyśmy tak daleko.
Przepraszam, ale nie zdołałem sam obronić tego, co wspólnie zbudowaliśmy.
------
𝐃𝐥𝐚𝐜𝐳𝐞𝐠𝐨 𝐨𝐩𝐞𝐫𝐚𝐭𝐨𝐫𝐳𝐲 𝐰 𝐏𝐨𝐥𝐬𝐜𝐞 𝐳𝐚𝐛𝐥𝐨𝐤𝐨𝐰𝐚𝐥𝐢 𝐝𝐨𝐬𝐭ę𝐩 𝐝𝐨 𝐝𝐚𝐧𝐲𝐜𝐡 𝐳 𝐢𝐧𝐭𝐞𝐥𝐢𝐠𝐞𝐧𝐭𝐧𝐲𝐜𝐡 𝐥𝐢𝐜𝐳𝐧𝐢𝐤ó𝐰?
𝐎𝐟𝐢𝐜𝐣𝐚𝐥𝐧𝐞 𝐚𝐫𝐠𝐮𝐦𝐞𝐧𝐭𝐲 𝐨𝐩𝐞𝐫𝐚𝐭𝐨𝐫ó𝐰 (𝐎𝐒𝐃):
1. 𝐁𝐞𝐳𝐩𝐢𝐞𝐜𝐳𝐞ń𝐬𝐭𝐰𝐨 𝐝𝐚𝐧𝐲𝐜𝐡 (𝐑𝐎𝐃𝐎, 𝐢𝐧𝐟𝐫𝐚𝐬𝐭𝐫𝐮𝐤𝐭𝐮𝐫𝐚 𝐤𝐫𝐲𝐭𝐲𝐜𝐳𝐧𝐚) – OSD argumentują, że dane z liczników jako dane osobowe wymagają szczególnej ochrony. W praktyce jednak, choć podlegają RODO, nie są to dane wrażliwe (jak np. dane medyczne), a ich skuteczne zabezpieczenie jest standardowym wyzwaniem technologicznym, które można rozwiązać bez całkowitej blokady.
2. 𝐎𝐜𝐡𝐫𝐨𝐧𝐚 𝐩𝐫𝐳𝐞𝐝 𝐦𝐚𝐧𝐢𝐩𝐮𝐥𝐚𝐜𝐣ą 𝐥𝐢𝐜𝐳𝐧𝐢𝐤𝐢𝐞𝐦 – Podnoszony jest argument, że otwarty port mógłby pozwolić na ingerencję w oprogramowanie licznika. W rzeczywistości jest to urządzenie wyłącznie do odczytu, a ryzyko takiej ingerencji jest minimalne i zabezpieczane na poziomie firmware’u.
3. 𝐒𝐭𝐚𝐧𝐝𝐚𝐫𝐲𝐳𝐚𝐜𝐣𝐚 𝐬𝐲𝐬𝐭𝐞𝐦𝐮 𝐀𝐌𝐈 (𝐀𝐝𝐯𝐚𝐧𝐜𝐞𝐝 𝐌𝐞𝐭𝐞𝐫𝐢𝐧𝐠 𝐈𝐧𝐟𝐫𝐚𝐬𝐭𝐫𝐮𝐜𝐭𝐮𝐫𝐞) – Operatorzy dążą do pełnej kontroli nad przepływem informacji w swoim centralnym systemie, traktując lokalny dostęp jako element zakłócający ten model.
𝐑𝐳𝐞𝐜𝐳𝐲𝐰𝐢𝐬𝐭𝐞 𝐦𝐨𝐭𝐲𝐰𝐚𝐜𝐣𝐞 𝐛𝐢𝐳𝐧𝐞𝐬𝐨𝐰𝐞 𝐢 𝐭𝐞𝐜𝐡𝐧𝐨𝐥𝐨𝐠𝐢𝐜𝐳𝐧𝐞:
1. 𝐊𝐨𝐧𝐭𝐫𝐨𝐥𝐚 𝐧𝐚𝐝 𝐝𝐚𝐧𝐲𝐦𝐢 𝐭𝐨 𝐤𝐨𝐧𝐭𝐫𝐨𝐥𝐚 𝐧𝐚𝐝 𝐫𝐲𝐧𝐤𝐢𝐞𝐦 – Dane o zużyciu energii w czasie rzeczywistym to cenny zasób. Pozwalają tworzyć nowe usługi, dynamiczne taryfy, prognozy i modele biznesowe. Kto kontroluje dane, ten kontroluje przyszłość rynku energetycznego.
2. 𝐇𝐚𝐦𝐨𝐰𝐚𝐧𝐢𝐞 𝐫𝐨𝐳𝐰𝐨𝐣𝐮 𝐧𝐢𝐞𝐳𝐚𝐥𝐞ż𝐧𝐲𝐜𝐡 𝐬𝐲𝐬𝐭𝐞𝐦ó𝐰 𝐩𝐫𝐨𝐬𝐮𝐦𝐞𝐧𝐜𝐤𝐢𝐜𝐡 – Swobodny dostęp do danych pozwoliłby użytkownikom na efektywne zarządzanie własną energią, magazynami czy mikroinstalacjami – często bez potrzeby korzystania z płatnych lub ograniczonych usług operatora, które opierają się na danych z naszych własnych liczników.
3. 𝐖𝐲𝐳𝐰𝐚𝐧𝐢𝐚 𝐰𝐝𝐫𝐨ż𝐞𝐧𝐢𝐨𝐰𝐞 𝐢 𝐰𝐲𝐛ó𝐫 𝐧𝐚𝐣𝐩𝐫𝐨𝐬𝐭𝐬𝐳𝐲𝐜𝐡 𝐫𝐨𝐳𝐰𝐢ą𝐳𝐚ń – Zamiast opracować i wdrożyć bezpieczny, autoryzowany dostęp do portu (np. za pomocą kodu PIN, jak w innych krajach UE), wybrano drogę na skróty: całkowitą blokadę jako rozwiązanie najprostsze i najtańsze w implementacji.
𝐏𝐫𝐚𝐰𝐨 𝐞𝐮𝐫𝐨𝐩𝐞𝐣𝐬𝐤𝐢𝐞 𝐬𝐭𝐨𝐢 𝐩𝐨 𝐬𝐭𝐫𝐨𝐧𝐢𝐞 𝐤𝐨𝐧𝐬𝐮𝐦𝐞𝐧𝐭𝐚:
- 𝐃𝐲𝐫𝐞𝐤𝐭𝐲𝐰𝐚 𝟐𝟎𝟏𝟗/𝟗𝟒𝟒/𝐔𝐄 (𝐚𝐫𝐭. 𝟐𝟑) wyraźnie przyznaje odbiorcom prawo do „bezpłatnego i łatwego dostępu do swoich danych pomiarowych w czasie zbliżonym do rzeczywistego (near real-time)”.
- 𝐑𝐎𝐃𝐎 (𝐚𝐫𝐭. 𝟐𝟎) zapewnia użytkownikowi prawo do przenoszenia danych i kontroli nad nimi. Oznacza to, że to konsument, a nie operator, powinien decydować o wykorzystaniu swoich danych.
- 𝐖𝐳𝐨𝐫𝐜𝐞 𝐳 𝐢𝐧𝐧𝐲𝐜𝐡 𝐤𝐫𝐚𝐣ó𝐰 𝐔𝐄 – Nie musimy wymyślać koła na nowo. Wystarczy sięgnąć po sprawdzone rozwiązania z innych krajów UE. W Niemczech użytkownik może bez problemu odczytać lokalnie podstawowe dane, a po wprowadzeniu kodu PIN uzyskać dostęp do danych historycznych. Rozwiązanie to jest bezpieczne i szanuje prawa konsumenta.
𝐃𝐥𝐚𝐜𝐳𝐞𝐠𝐨 𝐛𝐥𝐨𝐤𝐚𝐝𝐚 𝐩𝐨𝐫𝐭𝐮 𝐭𝐨 𝐝𝐳𝐢𝐚ł𝐚𝐧𝐢𝐞 𝐦𝐨𝐧𝐨𝐩𝐨𝐥𝐢𝐬𝐭𝐲𝐜𝐳𝐧𝐞?
1. 𝐄𝐥𝐢𝐦𝐢𝐧𝐮𝐣𝐞 𝐤𝐨𝐧𝐤𝐮𝐫𝐞𝐧𝐜𝐣ę 𝐧𝐚 𝐫𝐲𝐧𝐤𝐮 𝐮𝐬ł𝐮𝐠 𝐞𝐧𝐞𝐫𝐠𝐞𝐭𝐲𝐜𝐳𝐧𝐲𝐜𝐡 – Uniemożliwia działanie niezależnym firmom – takim jak OneMeter – które dostarczają narzędzia do zarządzania energią dla każdego odbiorcy, od gospodarstw domowych po przedsiębiorstwa.
2. 𝐃𝐲𝐬𝐤𝐫𝐲𝐦𝐢𝐧𝐮𝐣𝐞 𝐨𝐝𝐛𝐢𝐨𝐫𝐜ó𝐰 𝐢 𝐩𝐫𝐨𝐬𝐮𝐦𝐞𝐧𝐭ó𝐰 – Odbiera im narzędzie do świadomego zarządzania zużyciem i produkcją energii.
3. 𝐇𝐚𝐦𝐮𝐣𝐞 𝐭𝐫𝐚𝐧𝐬𝐟𝐨𝐫𝐦𝐚𝐜𝐣ę 𝐞𝐧𝐞𝐫𝐠𝐞𝐭𝐲𝐜𝐳𝐧ą 𝐢 𝐨𝐬ł𝐚𝐛𝐢𝐚 𝐠𝐨𝐬𝐩𝐨𝐝𝐚𝐫𝐤ę – Blokada dostępu do danych uniemożliwia firmom optymalizację procesów, integrację zielonej energii i raportowanie ESG, obniżając ich konkurencyjność. Jednocześnie dusi cały rynek innowacyjnych usług opartych na danych – od zaawansowanych systemów dla biznesu (BEMS), po rozwiązania dla prosumentów i inteligentnych domów.
4. 𝐔𝐭𝐫𝐰𝐚𝐥𝐚 𝐝𝐨𝐦𝐢𝐧𝐮𝐣ą𝐜ą 𝐩𝐨𝐳𝐲𝐜𝐣ę 𝐎𝐒𝐃 – Czyni z operatorów monopolistów nie tylko w kwestii dystrybucji energii, ale także w strategicznie ważnym obszarze danych.
5. 𝐁𝐫𝐚𝐤 𝐮𝐳𝐚𝐬𝐚𝐝𝐧𝐢𝐞𝐧𝐢𝐚 – Blokada nie ma solidnych podstaw technicznych ani prawnych, co udowadniają przykłady innych państw członkowskich UE.
𝐖𝐞𝐳𝐰𝐚𝐧𝐢𝐞 𝐝𝐨 𝐝𝐳𝐢𝐚ł𝐚𝐧𝐢𝐚: 𝐓𝐫𝐳𝐲 𝐤𝐫𝐨𝐤𝐢 𝐝𝐨 𝐨𝐝𝐛𝐥𝐨𝐤𝐨𝐰𝐚𝐧𝐢𝐚 𝐝𝐚𝐧𝐲𝐜𝐡 𝐞𝐧𝐞𝐫𝐠𝐞𝐭𝐲𝐜𝐳𝐧𝐲𝐜𝐡
Obecna sytuacja nie jest technologicznym, lecz decyzyjnym impasem. Aby go przełamać, konieczne są natychmiastowe i zdecydowane działania ze strony kluczowych instytucji państwa, które muszą wyegzekwować od Operatorów (OSD) realizację praw konsumentów.
1. 𝐌𝐢𝐧𝐢𝐬𝐭𝐞𝐫𝐬𝐭𝐰𝐨 𝐊𝐥𝐢𝐦𝐚𝐭𝐮 𝐢 Ś𝐫𝐨𝐝𝐨𝐰𝐢𝐬𝐤𝐚: 𝐏𝐫𝐨𝐬𝐭𝐚 𝐳𝐦𝐢𝐚𝐧𝐚 𝐰 𝐏𝐫𝐚𝐰𝐢𝐞 𝐞𝐧𝐞𝐫𝐠𝐞𝐭𝐲𝐜𝐳𝐧𝐲𝐦.
Konieczny krok: Znowelizowanie Prawa energetycznego poprzez nałożenie na OSD obowiązku udostępnienia standardowego, otwartego interfejsu lokalnego (API) w każdym inteligentnym liczniku. Obowiązek ten musi polegać na zapewnieniu dostępu zgodnego z międzynarodowymi normami (np. IEC 62056/DLMS/COSEM), a nie na tworzeniu uznaniowego procesu certyfikacji poszczególnych urządzeń firm trzecich. Model dostępu powinien być dwupoziomowy:
- Poziom 1 (Dostęp podstawowy, bez autoryzacji): Zagwarantowanie stałego, nieautoryzowanego dostępu do kluczowych rejestrów licznika (całkowite zużycie i energia oddana). Taki dostęp jest w pełni bezpieczny i wystarczający dla podstawowych systemów monitoringu. W przypadku liczników z DLMS, jego uruchomienie nie wymaga wymiany sprzętu, a jedynie prostej zmiany konfiguracji przez operatora.
- Poziom 2 (Dostęp rozszerzony, po autoryzacji): Umożliwienie konsumentowi dobrowolnego odblokowania (np. kodem PIN) dostępu do danych szczegółowych, niezbędnych do zaawansowanego zarządzania energią.
2. 𝐔𝐫𝐳ą𝐝 𝐑𝐞𝐠𝐮𝐥𝐚𝐜𝐣𝐢 𝐄𝐧𝐞𝐫𝐠𝐞𝐭𝐲𝐤𝐢: 𝐄𝐠𝐳𝐞𝐤𝐰𝐨𝐰𝐚𝐧𝐢𝐞 𝐩𝐫𝐚𝐰𝐚 𝐞𝐮𝐫𝐨𝐩𝐞𝐣𝐬𝐤𝐢𝐞𝐠𝐨.
Konieczny krok: Wszczęcie postępowań kontrolnych u Operatorów w sprawie systematycznego naruszania praw konsumentów do bezpłatnego i łatwego dostępu do danych (gwarantowanego przez Dyrektywę 2019/944/UE). Inercja regulatora jest niezrozumiała, zwłaszcza że techniczne bariery podnoszone przez OSD są iluzoryczne.
3. 𝐔𝐫𝐳ą𝐝 𝐎𝐜𝐡𝐫𝐨𝐧𝐲 𝐊𝐨𝐧𝐤𝐮𝐫𝐞𝐧𝐜𝐣𝐢 𝐢 𝐊𝐨𝐧𝐬𝐮𝐦𝐞𝐧𝐭ó𝐰: 𝐙𝐛𝐚𝐝𝐚𝐧𝐢𝐞 𝐩𝐫𝐚𝐤𝐭𝐲𝐤 𝐦𝐨𝐧𝐨𝐩𝐨𝐥𝐢𝐬𝐭𝐲𝐜𝐳𝐧𝐲𝐜𝐡.
Konieczny krok: Wszczęcie postępowania wyjaśniającego w sprawie nadużywania pozycji dominującej przez OSD. Ich skoordynowane działania, polegające na blokowaniu dostępu do danych, które można udostępnić prostą zmianą konfiguracji, noszą znamiona celowego hamowania konkurencji na rynku innowacyjnych usług energetycznych.
𝐏𝐨𝐳𝐨𝐬𝐭𝐚𝐣𝐞 𝐨𝐭𝐰𝐚𝐫𝐭𝐞 𝐩𝐲𝐭𝐚𝐧𝐢𝐞: 𝐝𝐥𝐚𝐜𝐳𝐞𝐠𝐨 𝐭𝐞 𝐩𝐨𝐝𝐦𝐢𝐨𝐭𝐲 𝐭𝐞𝐠𝐨 𝐰𝐜𝐳𝐞ś𝐧𝐢𝐞𝐣 𝐧𝐢𝐞 𝐮𝐜𝐳𝐲𝐧𝐢ł𝐲?
------
Zależy mi, by ta historia nie była tylko historią upadku jednego startupu, lecz impulsem do naprawy systemu i przywrócenia zaufania między ludźmi, technologią i instytucjami.
Energetyka w Polsce potrzebuje otwartości, współpracy i zaufania – nie monopolu nad danymi. Wierzę, że ten list pomoże rozpocząć rozmowę, która przywróci energii jej prawdziwy sens — służenie ludziom.
Z wyrazami szacunku,
Mateusz Brzozowski
Twórca OneMeter
1 polubienie
They could have open-sourced the package of the gateway and let people to make it work locally. The package itself was communicating with the cloud using MQTT as I remember. I woulnd’t be rocket science to make it to talk to a local broker.
1 polubienie
czy ktoś ma pobrany plik onemeter-gateway-amd64-v2.2.deb z dokumentacji lub inny z oprogramowania bramki która potrafiła komunikować się z urządzeniem? Niestety dokumentacja nie działa, a te linki w niej też nie działały.
https://update.onemeter.com/package/gateway-package-amd64/latest
https://storage.googleapis.com/onemeter-gateway/package/onemeter-gateway-amd64-v2.2.deb
W sumie mam. Jak to wystawić?
1 polubienie
jest też starsza wersja
https://web.archive.org/web/20220117212521/https://storage.googleapis.com/onemeter-gateway/package/onemeter-gateway-amd64-v2.1.deb
wersja dla maliny
https://web.archive.org/web/20221127021752/https://storage.googleapis.com/onemeter-gateway/package/onemeter-gateway-armhf-v2.2.deb
i starsza dla maliny
https://web.archive.org/web/20220117223002/https://storage.googleapis.com/onemeter-gateway/package/onemeter-gateway-armhf-v2.1.deb
Spakuj do zip, wrzuć do załącznika, nie ma śladu po licencji, ale rozumiem, że była bardziej otwarta niż zamknięta?
Swoją drogą ciekawe, że można dostać kasę z funduszy europejskich na nieetyczną reklamę (pkt. 4)…
1 polubienie
onemeter-gateway-amd64-v2.2.zip (315,1 KB)
Proszę.
Mam nadzieję, że komuś uda się do tego dobrać, aby utworzyć coś lokalnego.
Szkoda projektu, bo był przydatny. Firma nie powinna tak po prostu obrazić się i zniknąć.
Pzdr.
Tomek.
W \etc\onemeter-gateway\ jest plik konfiguracyjny servers
który wskazuje na
mqtt.onemeter.com:1883 Server
więc tak patrząc na to z boku - może wystarczy tam podstawić własny lokalny broker
hmm, sądząc po stylu zniknięcia (nie otwarto kodu źródłowego) to był projekt na przytulenie unijnej dotacji… i zgaduję, że prokurator nie ma tam nic do roboty, bo pewnie ramy czasowe zostały wypełnione, niestety czasem dotacje prowadzą do patologii i wywołują efekt przeciwny do ich celu…
Czytałeś wyjaśnienie twórcy? To nie jest foch, tylko lata udręki i złych doświadczeń. Decyzja na pewno należała do tych najtrudniejszych w życiu.
Szczerze mówiąc nie interesowałem się tym projektem (nie wyróżniał się niczym szczególnym wśród innych podobnych), ale nabrałem jakiegoś zdania przeczesując internet w poszukiwaniu plików, które tu ktoś chce wykorzystać…
Jednak myślę, że to tylko dobra mina do złej gry = dobry PR, by mimo złych działań wyjść z twarzą. Lepiej było upublicznić kod, co być może jest nadal możliwe, bo jakoś nie wierzę, że w momencie podjęcia decyzji o zamknięciu tej działalności wyzerowano nośniki, nie wiadomo czy ktoś z tego zrobiłby użytek dla dobra dotychczasowych użytkowników, ale mam na myśli sam fakt braku tych pro-klienckich działań.
Czytałem, czytałem. Smutne trochę.
Ale równi smutni muszą być użytkownicy, którzy niedawno kupili rozwiązanie. Ja jestem już “po gwarancji”, więc jakoś przeżyję. Jeśli nikt tego nie ogarnie, to będę zmuszony szukać podobnych rozwiązań.