Każdy z nas – rozwijających swój inteligentny dom, chciałby mieć podgląd na ulice wokół swojego domu. Cel? Podgląd korków, obserwacja sąsiadów etc.

Na szczęście jest coś takiego jak traxelektronik.pl.

To firma która regularnie pokrywa nasz kraj kamerami a co więcej obraz z nich udostępnia na swoich stornach internetowych.

Dodając do tego HOME ASSISTANT i scrape sensor – możemy uzyskać to co chcemy.

 

Jak to zrobić?

Na początku wyszukujemy interesujące nas kamery na stronie:  https://www.traxelektronik.pl/pogoda/kamery/index.php

Następnie wybieramy interesującą nas miejscowość i zapamiętujemy adres z przeglądarki

 

W demonstrowanym przypadku naszym adresem będzie:

https://www.traxelektronik.pl/pogoda/kamery/kamera.php?pkamnum=1960

No i teraz do dzieła. W home assistant definiujemy sensory typu scrape jak w poniższym listingu:


# kamerki zewnętrzne, skrapowanie
# https://www.traxelektronik.pl/pogoda/kamery/

- platform: scrape
  resource: https://www.traxelektronik.pl/pogoda/kamery/kamera.php?pkamnum=1960
  name: Url kamera traxel skawina (na rzeszów)
  id: url_kamera_traxel_skawina_na_rzeszow
  select: "#kam1 ~ a:nth-of-type(4)"
  #kam1 - numer kolejnej kamery
  value_template: >-
    {{ value.split("'")[1] }}
  attribute: href
  scan_interval: 60

- platform: scrape
  resource: https://www.traxelektronik.pl/pogoda/kamery/kamera.php?pkamnum=1960
  name: Url kamera traxel skawina (na katowice)
  id: url_kamera_traxel_skawina_na_katowice
  select: "#kam0 ~ a:nth-of-type(4)"
  #kam1 - numer kolejnej kamery
  value_template: >-
    {{ value.split("'")[1] }}
  attribute: href
  scan_interval: 60
* Z uwagi, że WP wycina niektóre znaki, plik ten do pobrania jest również artykułu. (Jeśli ktoś sobie z tym poradził – proszę o info)

 

U mnie definicja sensorów znajduje się w pliku sensor.yaml (polecam osobny plik).

Jeżeli u Ciebie sensory definiowane są w pliku configuration.yaml – musisz dodać wpis:

sensor:

przed definicją sensorów.

Nie będę opisywał szczegółowo jak działa sensor scrape. W skrócie… wykorzystując tak zwane selektory CSS wyszukujemy zdjęcie kamery:

select: “#kam0 ~ a:nth-of-type(4)”

A następnie wyciągamy potrzebną informację za pomocą:

value_template: >- {{ value.split(“‘”)[1] }} attribute: href

I proces ten przeprowadzamy dla każdej kamery którą chcemy mieć w swoim systemie inteligentnego domu.

 

Pozostaje kwestia definicji kamer. Realizujemy to za pomocą standardowej kamery HA generic. Poniżej skrypt:

# drogowe 
- platform: generic
  name: skawina (na rzeszów)
  id: traxel_skawina_na_rzeszow
  still_image_url: >-
    {{ states('sensor.url_kamera_traxel_skawina_na_rzeszow') }}

- platform: generic
  name: skawina (na katowice)
  id: traxel_skawina_na_katowice
  still_image_url: >-
    {{ states('sensor.url_kamera_traxel_skawina_na_katowice') }}

U mnie definicja kamer znajduje się w pliku camera.yaml (polecam osobny plik).

Jeżeli u Ciebie kamery definiowane są w pliku configuration.yaml – musisz dodać wpis:

camera:

przed definicją kamer.

 

Tak zdefiniowane kamery stają się widoczne w naszym panelu home assistant. U mnie dziś pada:-)

 

Pliki do artykułu:

camera.yaml, sensor.yaml > homeasistant-kamery-scrap-sensor

 

Postanowiłem zainstalować w domu alarm:-)

Cel?

Zabezpieczenie mieszkania przy poniższych założeniach:

  1. NAJWAŻNIEJSZE – Alarm ma być niezależny od domowego systemu zarządzania, DOMOTICZ nie działa – alarm działa
  2. Alarm ma pozwolić na wykorzystanie podłączonych pirów, innych czujników w systemie DOMOTICZ (analiza ruchu, zarządzanie oświetleniem)
  3. DOMOTICZ / HOME ASSISTANT  powinien umieć sterować wyjściami OUT alarmu
  4. DOMOTICZ / HOME ASSISTANT powinien umieć uzbroić/rozbroić  alarm – głównie chodzi o włączenie alarmu dla strefy nocnej (mój manipulator będzie przy drzwiach wejściowych, więc chcę móc załączać alarm nocny innym urządzeniem – np. switch XIAOMI)
  5. DOMOTICZ / HOME ASSISTANT powinien wiedzieć kiedy alarm jest uzbrojony – po uzbrojeniu powinien umieć wyłączyć urządzenia typu telewizor, żelazko, amplituner ..

Wstępne rozpoznanie urządzeń wskazało na SATEL INTEGRA 32 + ETHM1plus (400pln) + dedykowany kabel dedykowany połączeniowy (40 pln).
Wszyscy polecają, wszyscy go mają, działa z DOMOTICZ.

Poszukałem innych rozwiązań dostępnych na rynku i postanowiłem zaryzykować – bo spodobały mi się możliwości systemu ROPAM NEOGSM-IP – a tak będąc do końca szczerzy zostałem lekko ukierunkowany przez dobrego sprzedawcę, który zapewniał, że powyższe cele osiągnę właśnie z tym urządzeniem.

Jako, że nie jestem instalatorem, samo podłączenie urządzenia zajęło mi trochę czasu. Traktuję to jako zabawę połączoną z nauką,  więc czas na pewno nie uważam za zmarnowany.

Po kilku próbach, udało się skonfigurować urządzenie z jednym pirem, syreną i kartą GSM. Poniżej schemat który mi mocno pomógł, może kiedyś pomoże i Wam.

 

 

Pozostała kwestia integracji z DOMOTICZ.

Niestety na forum firmy ROPAM (link) możemy dowiedzieć się, że z tą centralką integracja nie jest możliwa.
Stwierdzenie “coś jest nie możliwe” jest mocno motywujące, tak więc wykorzystując jedną z moich ulubionych technik czyli Reverse Engineering postanowiłem mimo wszystko dokonać integracji.

Udało się.

W poniższym linku udostępniam program pozwalający na integrację systemu ROPAM NEOGSM-IP i DOMOTICZ HOME ASSISTANT i pewnie też z OPENHAB którego nie znam.

ropam-neogsm-domoticz-homeassistant-integrator

Program potrafi pracować jako usługa lub aplikacja konsolowa. Został napisany w technologii Microsoft .NET, ale, że zarówno ja, jak i większość z użytkowników systemu DOMOTICZ / HOME ASSISTANT korzysta z rozwiązania opartego o system LINUX, Raspberry … postanowiłem go uruchomić właśnie w tym środowisku.

I po raz kolejny udało się:-)

Poniżej kroki które należy uczynić by aplikacja zadziała na Raspberry:

  1. Instalujemy środowisko MONO (użyłem pełnej wersji, bo będę się jeszcze mocniej bawił)
    sudo apt-get install mono-complete
  2. Instalujemy MONO-SERVICE
    sudo apt-get install mono-4.0-service
  3. Pobieramy pliki programu do integracji z tego linka: ropam-neogsm-ip-dmoticz-intergracja
  4. Wrzucamy pobrane pliki (po rozpakowaniu) do docelowego katalogu (u mnie /home/pi/@scripts/neo/)
  5. Tworzymy plik uruchamiający usługę w katalogu naszego programu
    sudo nano xneoapi.sh

    Zawartość pliku:

    #!/bin/bash
    cd /home/pi/@scripts/neo/
    sudo mono-service -l:/var/run/lock/xneoapi.lock /home/pi/@scripts/neo/xneoapi.exe
    
  6. Nadajemy uprawnienia do uruchamiania skryptu
    sudo chmod +x xneoapi.sh
  7. Edytujemy plik /etc/rc.local wpisując:
    sudo nano /etc/rc.local
  8. Dodajemy poniższy wpis odpowiedzialny za automatyczne uruchamianie naszej usługi po restarcie Rasberrergo
    sudo /home/pi/@scripts/neo/xneoapi.sh
    
    

Pozostaje jeszcze kwestia integracji programu.

  1. Parametry pracy programu – plik xneoapi.exe.conf

     <applicationSettings>
            <X.NEO.API.Properties.Settings>
                <setting name="WebServerPrefix" serializeAs="String">
                    <value>http://localhost:7999/</value>
                </setting>
                <setting name="NeoGsmDeviceIp" serializeAs="String">
                    <value>192.168.1.100</value>
                </setting>
                <setting name="NeoGsmDevicePort" serializeAs="String">
                    <value>9999</value>
                </setting>
                <setting name="NeoGsmMainBoardId" serializeAs="String">
                    <value>1500067240999999</value>
                </setting>
                <setting name="NeoGsmUserCode" serializeAs="String">
                    <value>1234</value>
                </setting>
                <setting name="NeoGsmTcpCode" serializeAs="String">
                    <value>dac281bf43999999</value>
                </setting>
                <setting name="RunAsService" serializeAs="String">
                    <value>False</value>
                </setting>
                <setting name="Simulation" serializeAs="String">
                    <value>False</value>
                </setting>
            </X.NEO.API.Properties.Settings>
        </applicationSettings>
    

    Parametry związane z urządzaniem NeoGsm nie będę omawiał a pozostałe to:

    WebServerPrefix – prefixy dla naszego API, pod tymi adresami dostępne będzie API i strona informacyjna – jeżeli bedzie to kilka interfejsów, oddzielamy średnikami
    RunAsService – czy usługa będzie uruchomiona jako serwis czy jako aplikacja konsolowa [True|False]
    Simulation – odpala aplikacje w trybie symulacji, działa tylko WebServer bez połączenia z centralką alarmową [True|False]

  2. Parametry powiadomień systemów zewnętrznych (np. DOMOTICZ / HOME ASSISTANT)  – znajdują się w pliku notification.xml – tam raczej wszystko jest jasne, jeśli nie proszę o informację zwrotną.
    <?xml version="1.0" encoding="utf-8"?>
    <Notification xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
    <Inputs>
    <NotificationInput>
    <Id>0</Id>
    <OnActivate>http://192.168.1.101:8080/json.htm?type=command&amp;param=udevice&amp;idx=236&amp;svalue=1</OnActivate>
    <OnDeactivate>http://192.168.1.101:8080/json.htm?type=command&amp;param=udevice&amp;idx=236&amp;svalue=0</OnDeactivate>
    </NotificationInput>
    </Inputs>
    <Zones>
    <NotificationZone>
    <Id>0</Id>
    <OnArm>http://user:password@192.168.0.1:8080/json.htm?type=command&amp;param=udevice&amp;idx=3&amp;svalue=0</OnArm>
    <OnDisarm>http://user:password@192.168.0.1:8080/json.htm?type=command&amp;param=udevice&amp;idx=3&amp;svalue=1</OnDisarm>
    </NotificationZone>
    </Zones>
    </Notification>
  3. Parametry logowania zdarzeń znajdują się w pliku NLOG.config – instrukcja jak go modyfikować znajduje się pod adresem: https://nlog-project.org/

Po uruchomieniu aplikacji, pod adresem wskazanym w parametrze WebServerPrefix dostępna będzie strona API.

Aplikacja jest w wersji mocno rozwojowej – najnowsza jej wersja działa już produkcyjnie ale czekam na Wasze pytania, propozycje modyfikacji.