Home Assistant i powiadamianie o statusie urządzeń w domu

 W Domoticz stworzyłem sobie w dzVents mały automat, który o wschodzie słońca informował mnie o 'statusie domu’. Jaka temperatura na dole, jaka w pokojach dzieciaków, itp. itd.

Aby zrealizować to samo w Home Assistant zrobiłem to na podstawie prostej automatyzacji i powiadamianiem na e-mail.

W Service data wstawiłem:

message: >-

  HA – temperatura w salonie: {{ states(’sensor.temperature_158d0001b95f89′) }}

  , w ogrodzie: {{ states(’sensor.temperatura_ogrod’) }}, u Zosi: {{

  states(’sensor.temperature_158d00019c915b’) }}, u Stasia {{

  states(’sensor.temperatura_staszek’) }}. Prognoza mówi: {{

  states(’sensor.dark_sky_summary_1d’) }} Moja kochana żona pojedzie do pracy {{

  states(’sensor.dorota’) }} minut.

Mała aktualizacja. Aby skonfigurować wysyłanie e-maili trzeba uzupełnić sekcję 'notify’ w configuration.yaml.

notify:

  – name: Cezar

    platform: smtp

    server: !secret email_server

    port: 587

    timeout: 15

    sender: !secret email_sender

    encryption: starttls

    username: !secret email_username

    password: !secret email_password

    recipient:

      – !secret email_cezar

    sender_name: My Home Assistant

Automatyzacja dla maniaków nadzoru czasu pracy urządzeń – On for 3 hours

Dzień dobry.

Mimo założenia paneli fotowoltaicznych drażni mnie fakt, że niektóre urządzenia chodzą dłużej niż powinny. Vide – subwoofer. Niby ma auto off, ale jakoś tak mam wrażenie (nie mierzyłem co prawda, a może powinienem), że jednak działa i 'żre’ prąd. 

A do tego – w Domoticz miałem taką fajną funkcję Off Delay. W Home Assistant nie mam jej wprost, trzeba było sobie zrobić automatyzację. Prostą i logiczną.

Clue to Automatyzacja z Triggerem z wpisanym czasem For. I tyle. Idę sprawdzić czy działa.

Kod do wpisania (na przykład w automations.yaml) poniżej:

– id: '1598439820253′

  alias: Subwoofer off after three hours

  description: ”

  trigger:

  – entity_id: switch.sonoff_gniazdko

    for: 03:00:00

    from: 'off’

    platform: state

    to: 'on’

  condition: []

  action:

  – entity_id: switch.sonoff_gniazdko

    service: switch.turn_off

  mode: single

Gniazdka Blitzwolf – wgrywamy Tasmota za pomocą Tuya Convert

Usssssss… Powitać… To były ciężkie dwa dni. Mentalnie, bo miałem dużo myślenia przez pierdołę… Ale po kolei…
Z serwisu BuyMeACoffee dostałem dwie wpłaty od czytelników (za co bardzo dziękuję), od razu więc kupiłem dwie wtyczki WiFi Blitzwolf BW-SHP6 z pomiarem energii. Od razu rzuca się w oczy mały rozmiar w stosunku do wtyczek na przykład Sonoff oraz innych na 433MHz – niezmiernie mnie w nich drażniło to, że zajmują dwa miejsca w gniazdku, przez co podwójne stawało się pojedyncze.
Te są małe, śliczne, kolorowo mrugają i komunikują się po WiFi – fantastycznie.
Jest oczywiście aplikacja firmowa Blitzwolf, ale kto by na nią patrzył… Zresztą – lepiej jej nie używać aby nie zaktualizować firmware, które może już wykluczyć Tuya-convert, którego użyłem do wgrania alternatywnego oprogramowania Tasmota.
Zasada jest taka – aktualnie praktycznie każde urządzenie aktualizuje oprogramowanie przez OTA (Over-The-Air programming). Wtyczki również. Tak samo jak czajniki, żarówki, oczyszczacze, itp. Takich czasów dożyliśmy. Kontaktują się serwerami tu i tam (przeważnie 'tam’, czyli w Chinach) wysyłając i odbierając dane. Cały trik polega na tym, aby zasymulować taki serwer i wgrać swoje oprogramowanie. Do tego przyda nam się Tuya-Convert, która umożliwia wgrania na przykład Tasmota.
Potrzebować będziemy:
– jakiekolwiek Raspberry Pi z WiFi na pokładzie lub donglem USB WiFi (albo podobne urządzenie na którym możemy uruchomić Tuya-Convert). U mnie zawsze wala się gdzieś wolna Malina
– urządzenie, które podłączymy do naszego 'serwera’ – na przykład telefon
– urządzenie, które chcemy przeprogramować – tu gniazdko SHP6
Zacząłem od instalacji Raspberry Pi OS (wcześniej Raspbian) – https://www.raspberrypi.org/downloads/raspberry-pi-os/ – wystarczy wersja Lite. Szybki flash karty SD (używając balenaEtcher lub Win32DiskImager), wrzucenie pustego pliku ssh na partycję boot (od razu przez ssh będziemy pracować, monitor nam nie jest potrzebny, ale oczywiście wedle gustu) i jesteśmy gotowi do rozpoczęcia prac.
WAŻNE jeżeli pracujemy przez ssh – Raspberry musi być podłączone po kablu, dlatego że Tuya-Convert stworzy hot-spot WiFi do którego podłączy się gniazdko, ergo – stracilibyśmy połączenie z naszym terminalem.
Polecam przestudiować stronę projektu: https://github.com/ct-Open-Source/tuya-convert
Komendy po kolei to:
– aktualizacja repozytorium i instalacja git
– pobranie kodu tuya-convert
– instalacja niezbędnego oprogramowania (dość długa)
– flash!
sudo apt-get update && sudo apt-get install git
git clone https://github.com/ct-Open-Source/tuya-convert
cd tuya-convert
./install_prereq.sh
 
./start_flash.sh
Na początku wytłumaczenie zasady działania oraz informacje o bezpieczeństwie.
Zamykanie używanych portów, w kolejnym kroku musimy:
– podłączyć na przykład telefon do sieci vtrust-flash (taką stworzy Raspberry Pi)
– wprowadzić urządzenie w tryb parowania – w gniazdku trzeba przytrzymać włącznik przez kilka sekund aż zacznie migać
Po poprawnym połączeniu mamy pytanie co chcemy wgrać, tutaj wybór pomiędzy powrotem do oryginalnego softu, espurna lub tasmota. Ja wgrywam tasmota.bin.
Kilka chwil, tadam!
Na laptopie podłączam się do wykrytego hot-spot tasmota.
Pod adresem 192.168.4.1 będzie już nasze nowe oprogramowanie 🙂 Podajemy naszą nazwę połączenie WiFi oraz hasło.
Po zmianie (jeżeli mamy włączone DHCP na routerze) adres zostanie przyznany automatycznie. Ja używam Advanced IP Scanner aby znaleźć adres IP nowego gniazdka.
Po połączeniu możemy zabrać się za konfigurację. Na początku mamy po prostu Generic Module, podstawowy.
Configuration -> Configure Module i zmieniamy na BlitzWolf SHP.
Możemy już włączyć i wyłączyć gniazdko. Pierwszy sukces.
I teraz ciekawostka. Jako że towar pochodzi z Chin, to bardzo często praktycznie te same wtyczki, gniazdka, czujniki są 'brandowane’ różnymi firmami. Podstawa jest ta sama, różni się czasem szczegółami. Z tego to oto powodu pojawiły się Template – czyli pewne 'sposoby’ wykorzystania GPIO (General Purpose Input/Output) w sprzętach różnych firm.
Dla mnie ważne było: https://templates.blakadder.com/blitzwolf_SHP6-15A.html. Ważne, bo na przykład dla gniazdka 10A jest inny template 😉
TERAZ WAŻNY MOMENT, który mnie wstrzymał na dwa dni :/ To, że podałem template NIE ZNACZY wcale, że on już działa. Teraz musimy wejść w Configuration -> Configure Other i ZAZNACZYĆ Activate. Bez tego przed dwa dni mogłem sterować gniazdkiem, ale nie miałem podanych odczytów poboru mocy i innych.
Taki template można również wpisać ręcznie pobierając go ze strony podanej wyżej – https://templates.blakadder.com/blitzwolf_SHP6-15A.html
Sprawa następna. Kalibracja. Na wymienionej stronie podany jest również link to kalibracji gniazdka, ponieważ czasem odczyty mogą się różnić po zakupie. Jak? Podłączyć coś, co ma stałe, pewne obciążenie. Ja kupiłem żarówkę 60 Watt i podłączyłem do gniazdka. Z tego co wiem nie warto stosować LEDów i ECO żarówek – mają zbyt mały pobór mocy aby miało to sens. A żarówka i tak mi się przydaje na strychu.
W konsoli wpisujemy PowerSet wartość i VoltageSet wartość.
Jak widzicie domyślnie załadowana jest dość stara wersja Tasmota – 8.1.0.2. Warto zaktualizować. Jak? Zawsze świeże są na stronie projektu: https://github.com/arendst/Tasmota/releases/
Trzeba sobie uświadomić, że gniazdka mają ograniczoną pojemność i muszą podczas aktualizacji przechować wersję aktualną softu, ponieważ w przypadku błędu ładowania nowego muszą ją podmienić, aby nie 'uceglić’ sprzętu. Dlatego zaczynamy od ładowania tasmota-lite.bin (mała, kompaktowa wersja), a dopiero później tasmota.bin/
Jeżeli wybierzemy od razu tasmota.bin wystąpi błąd.
Najpierw Minimal,
Później główna tasmota.
Gotowe.
W kolejnym kroku zajmiemy się automatyzacją i powiadomieniami na przykład w zmywarce czy pralce.
Aktualizacja. Odpowiadając na pytanie czytelnika: Aby wyłączyć czerwone światło LED wystarczy zmienić Template z:
na:

Home Assistant i Template – potężne narzędzie

Dobry wieczór. 

Funkcjonalnością, którą coraz bardziej w Home Assistant lubię jest template. Dokładniej platforma template (platform: template), bo tak jest nazywana w systemie.

To co w Domoticz osiągałem czasem za pomocą dzVents (czyli skryptów) tutaj mogę zrobić template. Czyli na przykład zmiana danych wyjściowych z czujnika (zamiast wartości zwracanej z angielskiego na polski), zmiana jednostek danych (Watt na KWatt), zmiana ikon przy zmianie statusu encji, itp. itd. 

Do tego również inne, jak 'wyciąganie’ atrybutów z niektórych czujników (bo jak inaczej przetłumaczyć sensor?).  Na zrzucie poniżej widać integrację z AccuWeather stworzoną przez naszego kolegę z Polski – https://github.com/bieniu (polecam również sprawdzenie jego konfiguracji Home Assistant – https://github.com/bieniu/home-assistant-config, BTW swoją też lada chwilę będę tak udostępniał).

Dla wyjaśnienia, te elementy znajdziecie w Developer Tools -> States, po wpisaniu filtra w Current entities. 

Co ciekawe – udostępnia ona procentowe prawdopodobieństwo wystąpienia opadów. Jak jednak to cholerstwo stamtąd wyciągnąć? Dane z pierwszego 'akapitu’ (temperature, humidity) są proste – state_attr i z głowy. Ale dalej? Chwilę nad tym siedziałem, musiałem finalnie poprosić autora o pomoc w rozwiązaniu zagadki. Dzielę się nią dalej z Wami. Kolejne elementy są tablicą danych na kolejne dni (zaznajomieni z programowaniem będą od razu wiedzieli o co chodzi). Sposób ich pozyskania do innego czujnika Home Assistant nie jest taki oczywisty, ale jak się zastanowić to logiczny.


– platform: template
  sensors:
    rain_precipitation:
    value_template: '{{ state_attr(„weather.home_2”, „forecast”)[1][„precipitation_probability”] }}’
    friendly_name: 'Rain precipitation for the next day’


Czyli: dla encji weather.home_2, sekcji forecast, mamy podane kolejne dni prognozy. Aby dostać się do dnia dzisiejszego musimy podać element tablicy o koordynacie [0], drugi dzień to [1] i tak dalej, pięć dni. 

Później wystarczy dodać do ui-lovelace.yaml.


Kolejna misja zakończona 🙂

Pierwsze efekty Buy My a Coffee – gniazdka BlitzWolf BW-SHP6

Dzień dobry! Jako że pierwsze osoby były na tyle miłe, że kupiły mi kawę, postanowiłem, że jednak ich nie 'przepiję’, tylko kupię coś, co się przyda do recenzji i integracji.
Przed chwilą dostarczone – śliczne, zgrabne gniazdka. Model w którym możemy skorzystać ze sprzętów potrzebujących więcej mocy – do 3450W. 
Cel – wgranie Tasmota poprzez Tuya Convert, później integracja i automatyzacje po podłączeniu pralki oraz zmywarki do naczyń.

Home Assistant oraz współpraca z inwerterem solarnym Solis i pvoutput.org

Zanabyliśmy panele fotowoltaiczne. Lubię podejście do korzystania ze źródeł energii, która i tak jest nam dana przez naturę.
A skoro je mam w domu, za punkt honoru obrałem sobie integrację z Home Assistant. Paradoksalnie – łatwiej byłoby to zrobić w Domoticz, ale skoro już wszystko przestawiłem na HA – trzeba było się napracować.
Ogólnie powinno być prosto – inwerter (w moim przypadku Solis) podaje dane przez WiFi (do systemu firmy Ginlong), odbieramy je wcześniej w Home Assistant. Ale tak dobrze to jest rzadko…
Musiałem zrobić to przez serwis zewnętrzny – https://pvoutput.org/. To taki agregat zbierający dane – można tam wysłać zarówno zużycie jak i pozyskaną energię solarną. Owszem, niestety, z kolejnym 'tworem’ podzieliłem się nimi :/ Jeżeli znajdę prostszy sposób, postaram się pozyskiwać dane bezpośrednio z inwertera.
Przy okazji – przestał mi pokazywać poprawne wartości mój Owl Micro+. Niestety, nie jest 'kierunkowy’, czyli pokazuje mi teraz jednocześnie i zużycie i dostarczanie energii przez baterie solarne. Ale to temat na inny artykuł.
Zacząłem od utworzenia konta i stworzenia klucza API.
W zależności od inwertera na pewno trzeba skorzystać z innych integracji, ja znalazłem GinMon – https://github.com/wessel145/GinMon
Zgodnie z instrukcją najpierw wyszukałem: plantId a później deviceId.
"plantId":
https://m.ginlong.com/cpro/epc/plantDevice/inverterListAjax.json?plantId=
"deviceId":
Do pliku konfiguracyjnego /GinMon/config.ini wpisałem:
– username – do serwisu Ginlong
– password
– inverterID – to można znaleźć na wewnętrznej stronie www inwertera
– API key
– i znalezione deviceId w systemID
W sumie dopiero pisząc ten tekst przypomniałem sobie, że można dane eksportować również do własnej bazy MariaDB – muszę to zrobić w kolejnym kroku i uniezależnić się od pvoutput.org.
Po konfiguracji sprawdzamy czy wszystko działa poprawnie:
python3 GinMon.py
Skoro wszystko jest w porządku, wrzucamy skrypt to crontab (przez crontab -e) i ustawiamy uruchamianie jak nam wygodnie, na przykład co 15 minut.
Później pozostaje dodanie integracji w Home Assistant: https://www.home-assistant.io/integrations/pvoutput oraz sensora w configuration.yaml
Do formatowania wartości użyjemy jak w dokumentacji (świetnej jak zwykle) template sensor.
  – platform: template
    sensors:
      power_generation:
        value_template: '{% if is_state_attr(„sensor.pvoutput”, „power_generation”, „NaN”) %}0{% else %}{{ state_attr(„sensor.pvoutput”, „power_generation”) }}{% endif %}’
        friendly_name: 'Generating’
        unit_of_measurement: 'Watt’
      energy_generation:
        value_template: '{% if is_state_attr(„sensor.pvoutput”, „energy_generation”, „NaN”) %}0{% else %}{{ „%0.2f”|format(state_attr(„sensor.pvoutput”, „energy_generation”)|float/1000) }}{% endif %}’
        friendly_name: 'Generated’
        unit_of_measurement: 'kWh’
I jesteśmy gotowi!
Próbowałem zrobić Utility meter aby mieć podany pobór godzinowy, dzienny i miesięczny, ale jakoś nie potrafię tego poprawnie skonfigurować :/

Home Assistant – Jak ułożyć dane w kartach aby były tak jak chcemy – tips and tricks

Powitać.
Jednym z potężnych i niezaprzeczalnych plusów Home Assistant jest możliwość jego dostosowania do naszych potrzeb.

Mam sobie kod jak poniżej:

      – entity: weather.dark_sky
        type: weather-forecast
      – entity: weather.home
        type: weather-forecast
      – entities:
          – entity: binary_sensor.burze_dzis_net_frost_warning
          – entity: binary_sensor.burze_dzis_net_heat_warning
          – entity: binary_sensor.burze_dzis_net_precipitation_warning
          – entity: binary_sensor.burze_dzis_net_storm_warning
          – entity: binary_sensor.burze_dzis_net_storms_nearby
          – entity: binary_sensor.burze_dzis_net_tornado_warning
          – entity: binary_sensor.burze_dzis_net_wind_warning
        type: entities
który wygląda tak:
Używając dodatku Vertical stack https://www.home-assistant.io/lovelace/vertical-stack/ możemy te karty połączyć ze sobą. Oczywiście jest to jeden z przykładów, bo można łączyć różne elementy i encje w jeden pionowy zestaw.
      – type: vertical-stack
        in_card: true
        cards:
          – entity: weather.dark_sky
            type: weather-forecast
          – entity: weather.home
            type: weather-forecast
          – entities:
              – entity: binary_sensor.burze_dzis_net_frost_warning
              – entity: binary_sensor.burze_dzis_net_heat_warning
              – entity: binary_sensor.burze_dzis_net_precipitation_warning
              – entity: binary_sensor.burze_dzis_net_storm_warning
              – entity: binary_sensor.burze_dzis_net_storms_nearby
              – entity: binary_sensor.burze_dzis_net_tornado_warning
              – entity: binary_sensor.burze_dzis_net_wind_warning
            type: entities
Aby połączyć je natomiast poziomo możemy skorzystać z Glance https://www.home-assistant.io/lovelace/glance/ :
        – type: glance
          no_card: true
          title: „Salon”
          show_name: false
          entities:
            – sensor.salon_flora_temperature
            – sensor.humidity_158d000163e802
            – sensor.salon_flora_light_intensity
            – sensor.salon_flora_moisture
Z kolei menu 'Drop down’ jest już trochę bardziej czasochłonne, ale również proste.
W configuration.yaml zdefiniowałem sobie plik dla takich właśnie przełączników:
input_select: !include input_select.yaml
W tym oto pliku:
light_scenes_tv:
  name: „LED za TV”
  icon: mdi:palette
  options:
    – „ledzatvonwhite”
    – „ledzatvonblue”
    – „ledzatvonfade”
    – „ledzatvoff”
W ui-lovelace.yaml
– input_select.light_scenes_tv
A pod konkretne nazwy podpiąłem Automatyzacje:
– id: '1589838898697′
  alias: LED za TV white
  description: ”
  trigger:
  – entity_id: input_select.light_scenes_tv
    platform: state
    to: ledzatvonwhite
  condition: []
  action:
  – scene: scene.led_za_tv_white
I scena:
– id: ledzatvonwhite
  name: LED za TV white
  entities:
    switch.ledzatv: on
    switch.ledzatvwhite: on
Oraz, żeby było śmieszniej, to wywołuje kody IrDA w Broadlink 🙂
  – platform: broadlink
    host: 192.168.1.119
    mac: 34:EA:34:CE:00:CC
    switches:
      ledzatv:
        friendly_name: „LED za TV”
        command_on: 'JgBQAAABR5QXERYRFxEWERYRFxEWERYRFjcWNxY2FzYWNxY2FzYXNhY3FhEXNhc2FhEWEhYRFhEWERc2FhEXERY2FjcWNhc2FgAFFAABR0oVAA0FAAAAAAAAAAA=’
        command_off: 'JgBYAAABUZMXERYRFxEWERcRFhIWERcRFjcXNhc2FzcXNhc2FzYYNhY3FzYXNhg2FzYXEhcRFxEWEhcRFxEXERgRFzYXNhg2FwAFFQABU0oXAAxdAAFSSRcADQU=’
  – platform: broadlink
    host: 192.168.1.119
    mac: 34:EA:34:CE:00:CC
    switches:
      ledzatvwhite:
        friendly_name: „LED za TV white”
        command_on: 'JgBYAAABTJUVERUVExMVExUSFRUTExQTFTgVOBU3FjgWNhc2FjgRPRU3FhQTORUbDDkUExUUExQVFhE3FhMUOBcSFDkUOBU4FgAFGAABS0oWAAxgAAFOSRcADQU=’
        command_off: 'JgBYAAABTJUVERUVExMVExUSFRUTExQTFTgVOBU3FjgWNhc2FjgRPRU3FhQTORUbDDkUExUUExQVFhE3FhMUOBcSFDkUOBU4FgAFGAABS0oWAAxgAAFOSRcADQU=’
Może da się łatwiej, ale na ten moment inaczej nie potrafię 😉
Dwie rzeczy:
– ja uwielbiam 'babrać się’ w skryptach i plikach konfiguracyjnych. To mi daje poczucie pełnej kontroli
– uważajcie na wcięcia w tekście! To jest YAML i bardzo ważne są odstępy, odpowiednie marginesy

Home Assistant i aktualizacje dodatków

Jedna z rzeczy, która mnie niezmiernie drażniła w Domoticz to brak informacji o aktualizacjach komponentów. Jeżeli nawet coś się udało dowiedzieć, to konia z rzędem temu, kto wiedział co zaktualizowano… 

Jakże inaczej wygląda to w Home Assistant.
Po pierwsze, w jednym miejscu zebrane wszystkie aktualizacje, które możemy pobrać:
Po drugie każda z nich ma dokładny changelog i releasenotes:
Gdzie możemy się dowiedzieć co zostało zaktualizowane i kiedy. Ułatwia to niesamowicie zorientowanie się w problemie, jeżeli takowy wystąpi po aktualizacji dodatku. Na przykład gdy zostaną dodane/usunięte parametry.
Uwielbiam taki sposób podawania informacji i szanowania użytkownika. Czytelne, proste, działające.

Home assistant i dodanie nowego, niestandardowego repozytorium. Z przykładem :)

Bam. Dzień dobry. Home Assistant jest dla mnie coraz bardziej czytelny i potężny. Do tego, jak już pisałem, ilość oficjalnych dodatków powala na kolana. Ale są też te mniej oficjalne, które nie weszły jeszcze do HACS (Home Assistant Community Store) i można je dodać ręcznie. Poniżej przykład takiego właśnie dodatku, który wpadł mi w oko i spodobał się: Simple Scheduler. Pod adresem https://github.com/arthurdent75/SimpleScheduler macie dokładną instrukcję, ale przedstawia się ona jak poniżej:

Przechodzimy do Supervisor -> Add-on Store. W prawym górnym rogu wybieramy Repositories:

Dodajemy link, zamykamy. Pojawi się na naszej liście.

Przechodzimy na ten dodatek, instalujemy,

Po instalacji uruchamiamy.

Po tym procesie możemy przejść na stronę dodatku i przeprowadzić konfigurację.

Tak dla zasady dodałem uruchamianie światła o zachodzie słońca i wyłączenie o 23, tylko w weekendy.

Oczywiście można to zrobić w Automatyzacjach, ale dla samej zasady warto było zaprezentować.
Nie gwarantuję, że za tydzień, dwa ten dodatek nie wskoczy do HACS z którego będzie można go pobrać w jeszcze prostszy sposób.

Raspberry Pi 3 i start z dysku/pendrive USB

Dzień dobry.
’Do odważnych świat należy’, jak to mówią.
Do tej pory Raspberry startowałem z karty SD, później system był już ładowany z dysku HDD (http://blog.asobczak.pl/2018/01/31/przechodzimy-na-malinie-z-karty-sd-na-dysk-hdd-ssd/). Skoro jednak podjąłem decyzję o przejściu z Domoticz na Home Assistant, a po zmianie w bartopie na Raspberry Pi 4 została mi jedna wolna malinka w wersji trzeciej – 'raz kozie śmierć!’ pomyślałem i wykonałem jeden wpis w /boot/config.txt. Znamienny. 
Oczywiście żarty żartami, żadnych poważnych reperkusji to nie powoduje. Priorytetem jest zawsze karta SD i jeżeli znajdzie się w gnieździe – Raspberry wystartuje najpierw z niej.
Jak wcześniej napisałem – w /boot/config.txt dopisujemy jedną linię:
program_usb_boot_mode=1
i to w zasadzie cała filozofia. Przestawiany jest bit tak zwany OTP – One-time programmable, czyli taki, którego zawartość można zmienić wyłącznie raz. Nie można operacji odwrócić. Z tego co pamiętam w Raspberry Pi 3b+ jest już ustawiany domyślnie, fabrycznie.

Po wykonaniu komendy
vcgencmd otp_dump | grep 17:
ujrzymy informację po 17:. Jeżeli jest inna niż 3020000a znaczy to, że bit nie jest przestawiony. Czyli tak jak poniżej, przed restartem.

Ok, wpis w config.txt mamy, sprawdziliśmy czy już nie był ustawiony, robimy restart.
Bang, po chwili możemy sprawdzić, czy udało się poprawnie to zrobić:

3020000a jest zapisane, można wyjąć kartę i startować z SSD/USB/HDD. Działa, sprawdzałem. Tak przez pewien czas miałem uruchomiony Home Assistant. Aż do momentu gdy przeszedłem na Intel NUC 😉