Syr Safe-T Connect

Diese Seite beschreibt den Versuch die Ethernet-Verbindung des Sasserath Syr Safe-T Connect Leckage-Melders mit PRTG oder anderen Lösungen zu erfassen und ggfls. zu beeinflussen, z.B. als "Urlaubsschaltung" oder Alarmierung im Fehlerfall. Das "Connect" steht für eine Verbindung zum Internet und einer App auf einem Smartphone.

Funktionsprinzip

Die Firma Sasserath stellt neben Wasserenthärtungsanlagen (Siehe auch PRTG und Syr LexPlus 10) auch Leckage-Schutzsysteme her. Wer sich mal neben den Wasserzähler stellt, wird erkennen, dass dieser immer wieder "stoppt", d.h. ein Bewohner entnimmt wenige Liter für Kaffee-Kochen, mehrere Liter für Duschen oder WC-Spülung oder auch mal eine Badewannenfüllung (Meist 85-140 Liter). Auf jeden Fall ist immer mal wieder ein "Stop" dazwischen. Dieses Prinzip machen sich solche Geräte zu Eigen, indem Sie den Wasserverbrauch messen und die Leitung absperren, wenn mehr als eine gewisse Wassermenge (z.B.: 150 Liter) ohne Unterbrechung entnommen wird. Ein vergessener Wasserhahn oder ein geplatzter Schlauch fällt hier dann schon recht schnell auf und 150Liter sind immer noch weniger als ein überfluteter Keller mit durchweichten Wänden, Tapeten, Teppichen etc. Das gilt umso mehr in Neubauten, wenn die Keller "dicht" sind und keinen Bodenabfluss mehr haben, da das Abwasser-Niveau höher liegt. Als erweiterte Steigerung haben solche Geräte oft noch einen Eingang um einen Feuchtigkeitsmelder anzuschließen. Wenn also auf dem Boden Wasser steht, dann kann das Gerät auch die Wasserzufuhr stoppen.

Im Innern gibt es oben ein Kugelventil, welches per Motor gesperrt werden kann und unten eine Turbine, die den Wasserdurchfluss misst. Hier eine Schnittzeichnung aus dem Video auf der Homepage

Hier ist gut zu sehen, dass über den Universalflansch das Wasser in der Mitte in die Armatur  fließt und dann von unten nach Oben durch die Turbine. Diese Lösung ist dahingehend etwas unschön, dass ein zusätzlich auf dem Flansch angeschlossener Wasserenthärter wie der Syr LexPlus 10 zwar hinter der Absperreinrichtung aber vor der Turbine ist und damit eine Leckage an dieser Einheit nicht erkannt wird. Hier hilft dann nur ein zusätzlicher Bodensensor.

Wer so ein Gerät verbaut hat, sollte also ziemlich Ruhe vor Wasserschäden aufgrund defekter Leitungen, Schläuche oder vergessener Wasserhähne haben. Allerdings müssen Sie "Großverbraucher" dann vor dem Gerät anschließen. Dazu zählt insbesondere die Gartenbewässerung. 500 Liter/Stunde sind hier nichts und entsprechend wäre nach ca. 18 Minuten schon das Gießen unsanft beendet.

Anschluss und Aufbau

Der sanitäre Anschluss muss in der Regel ein zugelassender Sanitärbetrieb durchführen, da wir hier kurz hinter der Wasseruhr in die Trinkwasserleitung eingreifen. Hier gilt es also sauber und "dicht" zu arbeiten. Der normale Laie hat oft nicht die Möglichkeit die entsprechenden Flasche einzubinden und aufzupressen. In der Regel sind das aber nicht mehr als 2-3 Stunden Arbeit, die zu den Anschaffungskosten von 300-800€ dazu kommen. Bei mir klemmt er über einen Universalflansch an der Wasserleitung. auf der Vorderseite sieht man die Box des Wasserenthärters.

Seitlich sind die Anschlüsse für die Stromversorgung (Steckernetzteil) und den Feuchtigkeitssensor auf dem Boden. Das LAN-Kabel stellt die Verbindung zum Internet her. Darüber können Sie den Schriftzug "Batterie" lesen. Dahinter verbergen sich 4x 1,5V Zelle (AAA) als Notversorgung beim Spannungsausfall.

 

Auf der Unterseite sind die bereits belegten Anschlüsse für die verschiedenen Sensoren zu sehen und drei noch freie Anschlüsse, von denen nur zwei in der Dokumentation auch beschrieben werden. OUT und IN sind je ein externer Ausgang, der .z.B. bei einem Fehler geschaltet werden kann und ein externe Eingang, der als Signal für An/Abwesend oder als Wassermelder konfiguriert werden kann. Leider liegt im Paket der passende Steckverbinder nicht bei, so dass Suchen angesagt ist. Der Anschluss "Service" wird nicht beschrieben.

Der Service-Bus (RJ11-Buchse) stellt laut https://forum.iobroker.net/topic/56088/leckagesensor-syr-safe-t-connect-how-to-get-it-smart über die beiden mittleren Pins ein RS485-Protokoll mit 19200 Baud bereit.

Anscheinend ist das interne LAN-Modul auch nur als RS485-Ethernet-Gateway angebunden, denn laut Autor sieht man hier regelmäßig die Anfragen und Antworten.

Man sieht dort die Kommunikation zwischen dem LAN-Modul, welches die diversen Parameter abfragt, und dem Steuer-Mikrokontroller selber, der auf die Abfragen antwortet. Das LAN-Modul fragt jedoch nur regelmäßig die Parameter ab, wenn es mit einem Netzwerk verbunden ist. Andernfalls kommt nur alle paar Minuten eine kurze Abfrage des Gerätetyps.
Quelle: https://forum.iobroker.net/topic/56088/leckagesensor-syr-safe-t-connect-how-to-get-it-smart

Auf dem einfachen Display ist der aktuelle Status zu sehen. Ab 150 Liter Menge wird von einem Leck ausgegangen. Das "ANWESEND" signalisiert, dass immer mal wieder Wasser benötigt ist und daher nicht die "Urlaubsschaltung" angeht. Wenn z.B. drei Tage kein Wasser gezapft wird, dann macht das System "sicherheitshalber" zu. Im Moment ist die Absperrung aber auf und es werden gerade 21L/h entnommen. Selbst ein tropfender Wasserhahn mit gerade mal 1L/h wird erkannt.

Mechanisch macht die Box einen ganz ordentlichen Eindruck und kann auch ganz ohne Internet über die drei Folientasten eingerichtet werden.

Hinweis: Die Konfiguration selbst ist am Gerät nur möglich, wenn die LAN-Verbindung abgezogen ist. Sobald eine Verbindung per LAN besteht, ist am Display nur eine Anzeige möglich.

Die drei LEDs am oberen Rand signalisieren:

  • Impulse
    Blinkt für Volumen ähnlich einem Stromzähler, der pro Wh einmal blinkt. Bei einem Durchfluss von ca. 60L/h hat die LED ca. 100 Mal in einer Minute geblinkt, also ca. 6000/h. Insofern dürfte "ein Blinken" dann ca. 0,01L abbilden.
  • Alarm
    leuchtet rot, wenn ein Alarm anliegt
  • SYR Connect
    Blinkt einmal auf, wenn die Datenübertragung zur Cloud erfolgt

Insofern gibt es auch ohne LAN zumindest technische Möglichkeiten zum Abgreifen der wichtigen Zustände.

Willkommen im LAN

Über die auf dem Gehäuse aufgedruckte MAC-Adresse oder z.B. die Netzwerkliste in der Fritz!Box ist die per DHCP zugewiesene IP-Adresse schnell auszumachen und die Box reagiert auch auf eine HTTP-Anfrage. Leider ist aber auch diese Weboberfläche, wie beim Syr LexPlus 10, nicht wirklich freundlich für eigene Projekte aufgeschlossen. Im Gegensatz zum Syr LexPlus 10, der nur ein GIF-Bild liefert, kann hier über einfache Webformulare nur nicht die IP-Adresse und das Kennwort (Default = "syr") geändert werden. Die URLs sind:

# Netzwerkeinstellungen anzeigen
http://<ip>/netawork?in_passwd=syr&net=Enter 

#Netzwerkeinstellungen ändern
http://192.168.178.63/network?net_ip=192.168.178.63&mask=255.255.255.0&gateway=192.168.178.1&dns=192.168.178.10&dhcp=0&net=Apply 

http://<ip>/info?in_passwd=syr&net=Enter 
http://<ip>/admin?in_passwd=syr&net=Enter

Die Authentifizierung ist in der Art ungewöhnlich, dass die Anmeldeseite das Kennwort nicht als "Form Post" oder als Browser Authentifizierung liefert, sondern als Parameter an die URLs anhängt.

Laut LCD-Display ist die "Firmware Version 1.40b" installiert. Der WebServer ist ein "InterNiche ColdFireLite TCP/IP for ColdFire, v3.0". Wenn ich per Invoke-Webrequest die Seite abrufe, bekomme ich eine Protokollverletzung:

PS C:\> Invoke-WebRequest http://192.168.0.100 -UseBasicParsing
Invoke-WebRequest : Der Server hat eine Protokollverletzung ausgeführt.. Section=ResponseHeader Detail=Auf CR muss LF folgen

Im Wireshark ist aber schon die Antwort zu sehen und anscheinend sind Browser etwas toleranter als die PowerShell:

Allerdings ist über den Weg erst einmal keine weitere API ersichtlich gewesen.

Firmware Update

Eher zufällig habe ich bei der Erfassung der verschiedenen Befehle auch einen Firmware-Check mitschneiden können. Allerdings ist meine Box wohl schon aktuell genug, so dass es nur bei einem Status-Request bliebt. Die Anfrage geht an eine polnische Adresse (http://www.husty.pl/firmware/conv/version.cfg)

GET /firmware/conv/version.cfg HTTP/1.1
Host: www.husty.pl 
User-Agent: Husty Control-Box Bootloader
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: pl,en-us;q=0.7,en;q=0.3
Accept-Encoding: identity
Connection: keep-alive
Cache-Control: no-cache

Die Antwort liefert zumindest bei mir eine Versionsgeschichte als "Text"

PS C:\>(Invoke-WebRequest http://www.husty.pl/firmware/conv/version.cfg).rawcontent

HTTP/1.1 200 OK
Connection: keep-alive
Accept-Ranges: bytes
Content-Length: 1121
Content-Type: application/octet-stream
Date: Tue, 04 Apr 2023 08:41:30 GMT
ETag: "6012bddc-461"
Last-Modified: Thu, 28 Jan 2021 13:36:28 GMT
Server: nginx/1.6.2


1.84 - iot1.syrconnect.de hostname<br> 
1.83 - combi-hygienemodul AC error fixed
1.82 - override old settings
1.81 - encryption
1.80 - POST method, MQTT ports spy
1.79 - watchdog improvements
1.78 - reset converter after 3 minutes without SyrConnect
1.77 - added changes from red area ver. 1.80-1.89
1.76 - repaired getTYP cmd, added Bootloader version to web-interface
1.75 - added changes from meeting 17-19.07.14
1.73 - fixed problem with more than one leading/trailing spaces
1.72 - added reset after 3minutes without connection
1.71 - released some memory space to avoid hanging webserver
1.70 - support for device upgrading
1.61 - trimmed buffer lengths to support HVA device with 53 cmds
1.50 - fixed problem with hanging while receiving data, disabled CLKOUT pin
1.40 - supporting for older HTTP 1.0 protocol
1.30 - added reset to default settinds
1.20 - added SyrConnect configuration, fixed problem with 485 bus
1.11 - fixed problem with busy 485 bus, when not connected
1.10 - new version
1.00 - basic version

Über http://www.husty.pl/firmware/ bekommt man ein Verzeichnis, in dem einige Dateien zum Download liegen, die sie auch direkt herunterladen können.

Die Verzeichnisse lassen den Schluss zu, dass hier mehrere Hersteller mehr oder minder den gleichen Entwickler beschäftigen. "Pontosbase" ist eigentlich Hansgrohe und SafeT ist Syr und unter dem Ordner safetec3 findet sich eine Firmware mit dem Firmenname "Wilo". Für einen normalen Benutzer ist eine Firmware mit Zahlenketten (HEX-Format) nicht lesbar aber mit dem Wissen um die verwendete CPU lässt sich der Maschinencode durchaus lesbar machen. Mein System hat mittlerweile auch die Version 1.84.

Ich habe ja nichts gegen Firmware Updates und wenn diese automatisch erfolgen, ist das für Systeme mit permanenten Internetzugriff sicher auch in Ordnung. Auf der anderen Seite würde ich so etwas lieber manuell machen. Das Risiko ist mir sonst doch sehr hoch, dass jemand die Webseite mit einer "eigenen" Firmware versieht, die dann mit "LAN-Verbindung" in meinem Haus noch ganz andere Dinge anstellt. Es muss ja nicht mal mein LAN sein. Es reichen ja tausende dieser IoT-Devices um auch große Dienste per DoS zu stören.
Warum ist IoT immer nur dann sexy, wenn es per App über Internet funktioniert? Wo bleibt der lokale Zugang? Zumal der Zusammenhang von Sasserath, ConSoft als Webbetreiber und husty.pl als Firmware-Lieferant nicht offen gelegt sind.

Allerdings ist der Vorwurf nicht nur an Syr zu machen. Auch Grohe nutzt meines Wissens nach die Cloud ohne Rückfrage und Grünbeck scheint wohl bei ihrer Wasserenthärtung immer einen Default AccessPoint zu starten. (Anfang 2017). Auch hier gibt es also einiges an Updates zu erwarten.

Syr Webservice

Interessant ist hier, dass die URL des WebService ebenfalls geändert werden kann. Sie ging in einer alten Firmware noch per "http" auf folgende Adresse:

syrconnect.de/WebServices/SyrControlWebServiceTest2.asmx

Der Hostname löst auf die Adresse 212.77.236.30 auf, die laut IPInfo zu einem Provider in Quickborn gehört

Die unterstützten Methoden lassen sich sehr einfach über genau diese URL ermitteln.

In der Version 1.80 hat sich die URL geändert.

iot1.syrconnect.de/WebServices/SyrConnectDeviceWebService.asmx

Die IP-Adresse 212.77.236.125 ist beim gleichen Provider wie die vorherige Adresse. Der Webservice unter http://iot1.syrconnect.de/WebServices/SyrConnectDeviceWebService.asmx bietet nun einige Funktionen weniger an

Ich lass diese URL erst einmal, damit ich per Wireshark die POSTs und die Antworten mitschneiden kann. Schön, dass alles unverschlüsselt ist aber das ist ebenso schlecht, denn Anmeldedaten an dem WebService gibt es keine und über die Syr Connect Cloud kann das Gerät auch konfiguriert werden.

Natürlich mit App

Alles, was sich heute IoT nennt, muss eine App mitbringen. Exemplarisch hier die Bilder der kostenfreien IPhone-App, die ebenfalls mit dem WebService sprechen.

Wenn es jemandem also gelingt, die HTTP-Anfragen umzuleiten, was mangels SSL und Zertifikatsprüfung nicht sonderlich schwer sein wird, dann kann jemand auch die "passende" Antwort liefern um z.B. die Grenzwerte zu verändern oder auch einfach nur das Ventil zu schließen. Sollte die SyrCloud aus Kostengründen irgendwann "offline" gehen (Siehe auch Cloud - Abruptes Ende), dann funktioniert das alles nicht mehr.

Hallo ihr "Smart Home"-Hersteller. Wenn die Box immer mal wieder einen WebService aufruft, dann kann sie genau die Daten auch als UDP-Broadcast ins lokale Netzwerk posten. Dann wäre zumindest die Anzeige unabhängig. Oder der WebServer ist zumindest intern nicht nur zur Konfiguration sondern auch zum Auslesen und ggfls. Setzen von Werten aus dem gleichen Subnetz erreichbar.

Analyse Webservice

Ich möchte nicht, dass meine IoT Geräte unverschlüsselt und ohne Anmeldedaten mit einem Service in einer Cloud kommunizieren, zu dem es keinen Vertrag gibt. Die URL kann man natürlich anpassen und auf einen eigenen lokalen Service verweisen lassen.

Wenn ich dazu komme, dann würde ich diese Funktion z.B. als PHP-Seite oder ASPX für einen Webserver bauen, der die Daten dann bekommt und weiterleitet. Diesen Code gibt es aber noch nicht.

Dazu muss man natürlich erst einmal den vorhandenen Service auf die Finger schauen. Ich habe wieder mein Standard-Setup genutzt, bei dem der Switch-Port mit dem angeschlossenen Gerät auf einen PC gespiegelt wird, der mit Wireshark einfach die Pakete mitschneiden kann. Da auch hier ohne SSL gearbeitet wird, ist es sehr einfach die HTTP-Pakete zu analysieren. Alle 10 Sekunden sendet das Gerät einen "POST" an den WebService mir folgendem Inhalt (XML Einrückungen zur Lesbarkeit addiert). Jede de Zeilen repräsentiert eine Einstellung der Box und einige der Daten sind recht einfach zuzuordnen, z. B. "getBAT" enthält mit 6,48V die aktuelle Spannung der Überbrückungsbatterie. Die Antwort darauf ist ebenfalls unspektakulär, zumindest solange nichts "verstellt" wird. Es sind die gleichen Werte nur "leer".

Request Reply

Die Box sendet z.B. folgenden Request an den Webservice.

POST /WebServices/SyrControlWebServiceTest2.asmx/GetAllCommands HTTP/1.1
Host: syrconnect.de User-Agent: Husty Control-Box
Accept-Language: pl,en-us;q=0.7,en;q=0.3
Accept-Encoding: identity
Content-Type: application/x-www-form-urlencoded
Content-Length: 2023
Connection: keep-alive

xml=<?xml version="1.0" encoding="utf-8"?>
<sc>
  <d>
    <c n="1:setADM(2)f" v="FACTORY"/>
    <c n="1:getSRN" v="seriennummer"/>
    <c n="1:getVER" v="Safe-T%2b V1.40d"/>
    <c n="1:getUNI" v="0"/>
    <c n="1:getLNG" v="0 (0=Deutsch 1=English)"/>
    <c n="1:getBLT" v="00010"/>
    <c n="1:getDMA" v="1"/>
    <c n="1:getCNO" v="codenummer "/>
    <c n="1:getCEL" v="104"/>
    <c n="1:getBSI" v="2 (16 bar)"/>
    <c n="1:getAVO" v="0mL"/>
    <c n="1:getVOL" v="Vol[L]1596"/>
    <c n="1:getBSA" v="1"/>
    <c n="1:getFLL" v="0 50000"/>
    <c n="1:getEXI" v="0"/>
    <c n="1:getAWY" v="0 0 0 0"/>
    <c n="1:getSRV" v="07.12.17"/>
    <c n="1:getCEO" v="0"/>
    <c n="1:getDBD" v="10"/>
    <c n="1:getDBT" v="15"/>
    <c n="1:getDST" v="36"/>
    <c n="1:getDCM" v="3 min"/>
    <c n="1:getDOM" v="3 min"/>
    <c n="1:getDPL" v="10"/>
    <c n="1:getDTC" v="3 3"/>
    <c n="1:getDPH" v="2"/>
    <c n="1:getMEX" v="0"/>
    <c n="1:getTPA" v="32"/>
    <c n="1:getBOX" v="0"/>
    <c n="1:getFLG" v="125 250"/>
    <c n="1:getINT" v="0 0 0 0 0 0 1 0"/>
    <c n="1:getHUM" v=""/>
    <c n="1:getBUP" v="BUZ: Puls[100ms]:4 Periode[100ms]:60"/>
    <c n="1:getGLE" v="3"/>
    <c n="1:getGUL" v="0"/>
    <c n="1:getDSW" v="4"/>
    <c n="1:getDRP" v="1"/>
    <c n="1:getAEF" v="0"/>
    <c n="1:getUL" v="0"/>
    <c n="1:getTC" v="32"/>
    <c n="1:getNPS" v="1287"/>
    <c n="1:getFLO" v="2"/>
    <c n="1:getTO" v="1"/>
    <c n="1:getTYP" v="1"/>
    <c n="1:getVLV" v="20"/>
    <c n="1:getALA" v="FF"/>
    <c n="1:getALM" v="Alarms: FF A6 A6 -%26gt;A6 FF FF FF FF "/>
    <c n="1:getEN" v="20"/>
    <c n="1:getKW" v="KW 27/2001"/>
    <c n="1:getCTR" v="24"/>
    <c n="1:getLE" v="3"/>
    <c n="1:getREL" v="0"/>
    <c n="1:getT1" v="4"/>
    <c n="1:get48" v="2"/>
    <c n="1:getBAT" v="6,48 4,38 3,90"/>
    <c n="1:getTMP" v="0"/>
    <c n="1:getBRI" v="17"/>
    <c n="1:get71" v="0"/>
    <c n="1:getTN" v="1"/>
    <c n="1:getAB" v="1"/>
    <c n="1:getBAR" v="206 mbar"/>
    <c n="1:getBUZ" v="1"/>
    <c n="1:getT2" v="1"/>
    <c n="1:getNET" v="ADC:939 6,12V"/>
    <c n="1:clrADM" v="ADMIN RESET"/>
  </d>
  <ci m="MA:C-:AD:DR:ES:SE" f="1.80" b="3" />
  <cs v="A20A"/>
</sc>

Wenn es von der Cloud keine Konfigurationsänderungen gibt, dann kommt ein leere Datensatz zurück.

HTTP/1.1 200 OK
Cache-Control: private, max-age=0
Content-Type: text/xml; charset=utf-8
Server: Microsoft-IIS/8.5
X-AspNet-Version: 2.0.50727
X-Powered-By: ASP.NET
Date: Sat, 12 Nov 2016 21:49:08 GMT
Content-Length: 1961

<?xml version="1.0" encoding="utf-8"?>
<sc>
  <d>
    <c n="1:setADM" v="(2)f" />
    <c n="1:getSRN" v="" />
    <c n="1:getVER" v="" />
    <c n="1:getUNI" v="" />
    <c n="1:getLNG" v="" />
    <c n="1:getBLT" v="" />
    <c n="1:getDMA" v="" />
    <c n="1:getCNO" v="" />
    <c n="1:getCEL" v="" />
    <c n="1:getBSI" v="" />
    <c n="1:getAVO" v="" />
    <c n="1:getVOL" v="" />
    <c n="1:getBSA" v="" />
    <c n="1:getFLL" v="" />
    <c n="1:getEXI" v="" />
    <c n="1:getAWY" v="" />
    <c n="1:getSRV" v="" />
    <c n="1:getCEO" v="" />
    <c n="1:getDBD" v="" />
    <c n="1:getDBT" v="" />
    <c n="1:getDST" v="" />
    <c n="1:getDCM" v="" />
    <c n="1:getDOM" v="" />
    <c n="1:getDPL" v="" />
    <c n="1:getDTC" v="" />
    <c n="1:getDPH" v="" />
    <c n="1:getMEX" v="" />
    <c n="1:getTPA" v="" />
    <c n="1:getBOX" v="" />
    <c n="1:getFLG" v="" />
    <c n="1:getINT" v="" />
    <c n="1:getHUM" v="" />
    <c n="1:getBUP" v="" />
    <c n="1:getGLE" v="" />
    <c n="1:getGUL" v="" />
    <c n="1:getDSW" v="" />
    <c n="1:getDRP" v="" />
    <c n="1:getAEF" v="" />
    <c n="1:getUL" v="" />
    <c n="1:getTC" v="" />
    <c n="1:getNPS" v="" />
    <c n="1:getFLO" v="" />
    <c n="1:getTO" v="" />
    <c n="1:getTYP" v="" />
    <c n="1:getVLV" v="" />
    <c n="1:getALA" v="" />
    <c n="1:getALM" v="" />
    <c n="1:getEN" v="" />
    <c n="1:getKW" v="" />
    <c n="1:getCTR" v="" />
    <c n="1:getLE" v="" />
    <c n="1:getREL" v="" />
    <c n="1:getT1" v="" />
    <c n="1:get48" v="" />
    <c n="1:getBAT" v="" />
    <c n="1:getTMP" v="" />
    <c n="1:getBRI" v="" />
    <c n="1:get71" v="" />
    <c n="1:getTN" v="" />
    <c n="1:getAB" v="" />
    <c n="1:getBAR" v="" />
    <c n="1:getBUZ" v="" />
    <c n="1:getT2" v="" />
    <c n="1:getNET" v="" />
    <c n="1:clrADM" v="" />
  </d>
  <ct rt="10" />
</sc>

Sie können selbst sehen, dass hier ca. 2 Kilobyte gesendet und empfangen werden. Das passiert alle 10 Sekunden!. Entsprechend kommen hier 518400kByte/Monat = 506MB/Monat an Grundlast zusammen, selbst wenn die App gar nicht gestartet ist und niemand die Daten braucht.

Mit dem Request liefert das Gerät quasi ungefragt alle Daten an den Cloud-Service, der das dann wie folgt anzeigt:

Interessant ist hier die Messung des Volumens (kumuliert und gesamt), der Druck, eventuell die Temperatur und natürlich die Batterie. Syrconnect sendet aber auch eine Mail, wenn die Box etwas meldet.

Allerdings wurden die Mail bei mir als "Spam" klassifiziert. Der Header macht es einem Mailserver natürlich nicht einfach, wenn als Absender die Domäne "syr.de" genutzt wird und der einliefernde Mailserver mit der IP-Adresse 212.77.236.30 ganz woanders steht und der sogar noch per RDP erreichbar scheint und weder SPF noch DKIM dem Empfänger eine Chance geben den Absender zu qualifizieren. Da könnte der Anbieter mit wenige Aufwand die Zustellrate verbessern.

Return-Path: <isi@syr.de.nn>
Received: from mc01.omc.net ([212.77.228.145]) by mx.emig.kundenserver.de
 (mxeue003 [212.227.15.40]) with ESMTPS (Nemesis) id 0MFJnE-1c0BKG1Nem-00EOze
 for <franknn@carius.de>; Sun, 13 Nov 2016 00:23:12 +0100
Received: from WIN-NAHJ2SAG38O (www1.bitsign.omc.net [212.77.236.30])
	(Authenticated sender: cons7344@consoft.info)
	by mc01.omc.net (Postfix) with ESMTPA id 0BC819FBE2;
	Sun, 13 Nov 2016 00:23:12 +0100 (CET)
MIME-Version: 1.0
From: isi@syr.de
To: franknn@carius.de
Date: 13 Nov 2016 00:23:04 +0100
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: base64
Envelope-To: <franknn@carius.de>
Subject: [SPAM?] SYR CONNECT - Alarmhinweis

Interessant wird es, wenn die Einstellungen per Smartphone oder Browser verändert werden. Ich habe nicht mitgeschnitten, wie das Smartphone dies an den WebService sendet, sondern welche Antwort der WebService an die Box zurückliefert. Der Request ist wie oben immer komplett und auch die Antwort ist der gleiche Umfang. Nur die geänderten Einstellungen werden beim Abruf der Box einmalig übertragen. Folgende Zeilen ändern sich bei der Auswahl der entsprechenden Aktion.

Stufe Anwesend auf 100L              <c n="1:setLE" v="2" />
Stufe Anwesend auf 150L              <c n="1:setLE" v="3" />
Stufe Anwesend auf 200L              <c n="1:setLE" v="4" />

Zeitleckage 1,0 Stunden             <c n="1:setT1" v="2" />
Zeitleckage 1,5 Stunden             <c n="1:setT1" v="3" />
Zeitleckage 2,0 Stunden             <c n="1:setT1" v="4" />

Absperrung AUF                      <c n="1:setAB" v="1" />
Absperrung ZU                       <c n="1:setAB" v="2" />

Leckageschutz für 8h deaktivieren   <c n="1:setTMP" v="28805" />
Leckageschutz für 2h deaktivieren   <c n="1:setTMP" v="7200" />
Leckageschutz Anwesend              <c n="1:setTMP" v="0" />

Leckageschutz Anwesend              <c n="1:setUL" v="0" />
Leckageschutz Abwesend              <c n="1:setUL" v="1" />
Stufe Abwesend auf 20L              <c n="1:setUL" v="0" />

Es wird also nicht jedes Mal die komplette Konfiguration übertragen sondern nur die geänderten Werte. Soweit reicht mir das um die Funktionsweise zu verstehen.

Interessant bei der Konfiguration ist, dass nach dem "Absenden" einige Zeit vergeht, bis die App wieder reagiert. Im Hintergrund scheint Sie die Daten auf die Cloud zu speichern und dann darauf zu warten, dass das Gerät die Änderung abgeholt und seine neue Einstellung zurück gemeldet hat, was alle 10 Sekunden geschieht.

Lokaler Service 5333

Leider ist meine Syr Safe-T Connect lokal nur auf Port 80 für eine Konfiguration erreichbar. Wie ich weiter oben aber schon geschrieben habe, ist der Produzent "Hustly.pl" wohl nicht nur für Syr aktiv, sondern stellt vermutlich auch die Geräte für hansgrohe, Wilo und andere her. Entsprechend gibt es Hinweise diese Geräte in eine Home Automation einzubinden. So habe ich im Symcon-Forum entsprechende Kommentare gefunden, dass das "Pontos Base Wassermanagement" auf Port 5333 erreichbar ist und ein direktes Auslesen der Werte erlaubt. Das vermutlich baugleiche Geräte gibt es als "Syr Safe Tech" auch von Syr.

http://192.168.1.xxx:5333/pontos-base/get/all

Das gilt aber leider nicht für mein Safe-T Connect sondern nur für das fast gleich benannte SafeTech Connect. Ein NMAP zeigt bei mir nur Port 80 an

Ob es vielleicht eine Schnittstelle per UDP gibt, habe ich nicht ermitteln können.

Analoge API

Die Syr Connect App habe ich schon auf PRTG und Syr LexPlus 10 beschrieben. Auch der Leckageschutz nutzt die gleiche App und so ist anzunehmen, dass die APIs auch gleich sind und ich gar keinen neuen Sensor für PRTG bauen muss.

Aktuell habe ich entgegen meiner ersten Annahme keinen PRTG-Sensor umgesetzt. Die Alarmierung bei "Wasserschaden" erfolgt klassische per "Piepton" und dass eben kein Wasser mehr läuft. Ich würde mir aber schon wünschen, dass ich die Funktion auch ohne "Syr Connect" allein intern umsetzen kann. Vielleicht gibt es ja eine passende Schnittstelle (MQTT-Hinweise gibt es in den Versionsdokumenten

Eventuell funktioniert ja ein Umbau dahingehend, dass der WebService gar nicht die Cloud nutzt, sondern dass ich den Service lokal auf meinem PRTG-Server oder auf der Synology laufen lasse. Dann brauche ich die "Cloud" nicht mehr und fühle mich um einiges sicherer.

Einzig die Schaltkontakte, die es am Safe-T gibt, könnte man extern abgreifen.

Die potentialfreien Kontakte sind zumindest Niederspannung aber leider ist der Eingang nicht im TTL-Bereich (5V, 3,3V), so dass auch hier eine direkte Einbindung z.B. mit einem ESP8266 nicht möglich ist. Der Eingang IN2 dient wohl nur eine Leckage zu melden. So könnte man aber zumindest eine "Abschaltung" aus der Ferne aktivieren. Der OUT-Ausgang ist per Default deaktiviert und kann als Öffner, Schließer für Störungen oder als externe Ventilsteuerung genutzt werden. Hier könnte man recht einfach schon mal eine Meldung per ESP8266 via Mail, MQTT o.ä. absenden. Aber genau genommen will ich das gar nicht machen, wenn es doch schon ein LAN-Modul mit Webserver gibt. Ich hoffe ja immer noch darauf, dass es mal eine API gibt.

Eventuell werde ich aber vorher über den RS485-Port einen ESP32 anbinden, um meine eigene Netzwerkkopplung zu bauen, wenn seitens des Herstellers hier nichts kommt.

Syr2PRTG

Ich wollte natürlich schon die Daten des SafeT in meiner PRTG-Instanz haben. Ein Pollen durch einen PRTG - Custom Sensor direkt gegen den SafeT ist leider nicht möglich und eine Nutzung der Syr-Cloud stehe ich eher skeptisch gegenüber. Aber was sollte mich daran hindern, die Syr-Connect-URL auf einen lokalen Server zu verbiegen, auf dem dann ein kleiner HTTP-Service einfach nur die Daten annimmt und direkt an PRTG pusht. Auf der Seite PowerShell als HTTPServer habe ich die Vorarbeiten für einen HTTP-Listener gelegt und schnell einen POC gebaut, der erst einmal alle Anfragen annimmt, die Payload exportiert und die XML von oben zurück gibt. In der Konfiguration habe ich dann nur den Hostnamen auf die IP-Adresse geändert.

192.168.178.50/WebServices/SyrConnectDeviceWebService.asmx

Ein Wechsel auf HTTPS oder auch die Angabe eines anderen Ports ist nicht möglich. Die Anfragen kommen dann auch regelmäßig an.

SYR2PRTG: Start
------- New Request (1) at 20230404140353 arrived ------------
 URL.AbsoluteUri:http://192.168.178.50/WebServices/SyrConnectDeviceWebService.asmx/SetPortInfo
 HttpMethod     :POST
Exporting Body
------- Sending OK Response ------------
Listening on http://+:80/
------- New Request (2) at 20230404140355 arrived ------------
 URL.AbsoluteUri:http://192.168.178.50/WebServices/SyrConnectDeviceWebService.asmx/GetBasicCommands
 HttpMethod     :POST
No Body
------- Sending OK Response ------------
Listening on http://+:80/
------- New Request (3) at 20230404140408 arrived ------------
 URL.AbsoluteUri:http://192.168.178.50/WebServices/SyrConnectDeviceWebService.asmx/GetAllCommands
 HttpMethod     :POST
Exporting Body
------- Sending OK Response ------------
Listening on http://+:80/
------- New Request (4) at 20230404140421 arrived ------------
 URL.AbsoluteUri:http://192.168.178.50/WebServices/SyrConnectDeviceWebService.asmx/GetAllCommands
 HttpMethod     :POST
Exporting Body
------- Sending OK Response ------------
Listening on http://+:80/
------- New Request (5) at 20230404140434 arrived ------------
 URL.AbsoluteUri:http://192.168.178.50/WebServices/SyrConnectDeviceWebService.asmx/GetAllCommands
 HttpMethod     :POST
Exporting Body

Sie sehen gut am Anfang den SetPortInfo und dann den GetBasicCommands um dann alle 13 Sekunden einen POST auf "GetAllCommands" zu bekommen. Leider hat die aktuelle Firmware eine "Verschlüsselung", die die früher in Klartext übertragene XML nun einfach verändert. Ich vermute einfach mal, dass es sich um den Wert "<cp v="xxxx" /> um eine Art Codepage oder Version handelt und die Werte hinter "<dat" dann einfach zeichenweise ersetzt wurden, denn mit dem passenden Umbruch sehen wir schon Wiederholungen in zwei Requests.

Unverschlüsselt (Bis 1.80) Verschleiert (ab Firmware 1.81?)

Auf der einen Seite ist es lobenswert, die Klartext-Übertragung so etwas zu verschleiern. Allerdings wird es so natürlich erschwert, einen eigenen Webservice mit den Daten zu betreiben. Da ich aber ja eine Klartext-Version habe und ganz viele Ausgaben protokollieren kann, könnte über Buchstabenhäufigkeiten das decodieren gelingen. ASCII ist es aber wohl nicht, da der Zeichenraum durchaus mehr Zeichen hat und sogar ein "Euro"-Zeichen versteht.

Klartext

<

c

 

n

=

"

1

:

g

e

t
Verschleiert

Ä

}

ü

p

#

Ö

/

$

y

{

j
 

 

 

 

 

 

 

 

 

 

 

 

Ob es aber wirklich nur eine Verschiebung in Form einer "Caesar-Verschlüsselung" mit dem am Anfang mitgegebenen Offset ist, habe ich noch nicht ermittelt. Wenn Sie mögen, können Sie es ja mal versuchen.

Damit ist aber der Versuch einen passenden Service für eine lokale Verarbeitung zu schreiben erst mal in weite Ferne gerückt.

Anmerkungen

Wer auf die "Netzwerkanbindung" verzichten kann oder sich per LED-Abgriff und Schaltausgang selbst eine Steuerung baut, kann auch die einfachere Version SYR Safe-T LS-Modul Leckageschutzmodul 2421.00.000 DVGW oder vergleichbare Mitbewerber nutzen und ca. 300€ sparen. In Zeiten eines ESP8266 oder Raspberry Pico W sollte das alles kein Problem mehr sein.

Weitere Links