Syr LexPlus 10

Mit einer Härte von 14dH ist das Wasser in Hövelhof schon ziemlich kalkhaltig und Chromarmaturen setzen sehr schnell Ränder an. Also habe ich einige Zeit nach Wasserenthärtungsanlagen gesucht. Am Schluss wurde es eine Syr LexPlus Anlage, die zufällig auch mein Hausinstallateur vorgeschlagen hatte. ich war natürlich auch gespannt darauf, wie der Ethernet-Anschluss sich nutzen kann, z.B. für einen Einbindung in mein Monitoring mit PRTG. Ich habe in weiser Voraussicht schon CAT5-Anschlüsse in den Hausanschlussraum gelegt. Dort kommt ja auch DSL an. Einen passenden PRTG-Sensor habe ich auf PRTG und Syr LexPlus 10 beschrieben.

Hinweis
Dieser Artikel basiert auf einer Analyse im Herbst 2017. Im Feb 2019 wurde durch einen Servicetechniker ein Firmware Update auf Version 3.8 eingespielt. Die Veränderungen dazu habe ich unten angehängt.

Einstecken und Browser

Schon direkt nach dem Einstecken hat das Gerät eine IPv4-Adresse bezogen und über das Touch-Menü konnte ich die Daten ermitteln. Also schnell mal in einem Browser eingegeben und schon sehe ich das gleiche Bild, welches das Display anzeigt:

Soweit was das erst mal unspektakulär. Leider ist es auch wirklich nur eine "Ausgabe" der aktuellen Anzeige. Keine der Flächen kann angeklickt werden. Auf dem Gerät selbst kann ich genau den Wasserverbrauch, Regenerationsdaten, Wasserdruck etc. auslesen. Das System erfasst also schon eine Menge an Daten. Es gibt sogar eine "App" für IOS und Android. Da das Gerät aber im privaten LAN nicht erreichbar ist, sendet es die Daten natürlich in eine "Cloud". Also muss man doch erst mal genauer hinschauen, was das passiert.

Ein Portscan auf das Gerät ergab zumindest keinen direkt sichtbaren offenen Port. Leider liefert auch jede andere URL nur einen Fehler. Anscheinend liefert der Webserver wirklich nur das Bild aus, obwohl es doch sehr einfach wäre einfach die Werte auch als Text, XML, JSON-Ausgabe zusätzlich zu liefern.

Schaut man sich die Kommunikation mit Fiddler an, dann sieht man, dass es sich um einen "Server: MQX HTTPSRV/2.0 - Freescale Embedded Web Server v2.0" handelt, der eine kleine Default-Seite ausliefert, die nur das Bild per <img src="/sd/screenshot.bmp"> einbindet.

Diese einfache erlaubt ja schon mal die Einbindung in ein eigenes Anzeigeportal als Image. An die Daten kommt man so aber nicht ran.

Leider kenne ich keine weitere URL des Webservers, der z.B. eine JSON,/XML/CSV-Struktur geliefert hätte. Da hat der Hersteller das Potential nicht ausgenutzt.

Aber aufgrund des Werts in "Server" könnte man mutmaßen, dass die Plattform auf "Freescale MQX™ RTOS" basiert. Leider ist die Zielplattform damit kaum einzuschränken. Es kann ARM, ARC, PowerPC, xScale u.a. sein.

Kommunikation Lex-Plus zur Cloud

Diese Analyse basiert auf der Firmware 3.8. Im Jan 2021 ist Version 4.1 aktuell, die ich noch nicht weiter untersucht habe

Natürlich lasse ich ein Gerät an meiner Trinkwasserversorgung erst mal nicht ungefiltert ins Internet. Ich habe auch gar nicht den Wunsch, per App von unterwegs diese Daten zu nutzen und schon gar nicht diese zu Servern zu senden, zu denen ich kein Vertragsverhältnis habe. Datenschutz, Sicherheit und Dauerhaftigkeit sind meine Überlegungen, die Daten lokal abzufragen. Also habe ich den Switch-Port des Syr erst mal auf einem PC mit Wireshark gespiegelt und meine Befürchtungen haben sich bestätigt. Schön lesbare Kommunikation ohne HTTPS-Absicherung. Zumindest ist die Analyse damit natürlich auch sehr einfach und ich muss nicht mal die Kommunikation "knacken". Kaum hat die Anlage per DHCP eine IP-Adresse bekommen, sendet sie schon den ersten HTTP-Post.

Ich habe hier nicht alle Posts beschrieben, sondern nur eine Auswahl.

Hier sehen Sie die regelmäßigen HTTP-POST-Zugriffe der kleinen CPU auf einen Service in der Cloud. Der Hostname verweist aber nicht auf Sync sondern eine neue Firma in dem Umfeld

http://syrconnect.consoft.de

Eine Verschlüsselung wird nicht genutzt:

Als nächstes sendet er einen weiteren Post an einen Server in Polen, in dem die MAC-Adresse eine Seriennummer u.a. Daten gesendet werden.

Etwas später hat er noch eine ausführlichere Liste gesendet, in der noch viel mehr Daten hinterlegt waren. Eine komplette Wertemenge, die auf dem Gerät selbst als Grafik abrufbar ist, habe ich noch nicht gesehen. Vermutlich muss ich dazu die App installieren und deren indirekte Kommunikation über den Cloud-Proxy analysieren. Soweit wollte ich dann aber erst mal nicht gehen. Den ein oder anderen Fehler scheint es aber auch auf der Serverseite noch zu geben.

Die Anfragen mit ca. 250 Bytes und die Rückantworten mit ca. 670 Bytes und alle 10 Sekunden ergeben schon ein Download von 5 Megabyte/Tag oder 170 Megabyte/Monat. Auf der Seite des Clients wohl eher zu verschmerzen, so sie nicht gerade per GSM-Modem im Ferienhaus online sind. Aber auf der Provider-Seite wäre es mal interessant zu wissen, wie viel Bandbreite dort bereitgestellt werden muss.

Viel wichtiger ist die Frage, wie lange Syr diesen "Cloud Service" aufrecht erhalten kann, wenn der Kunde quasi nur einmalig über den Kaufpreis dafür bezahlt. Es gibt nämlich bei der Einrichtung keinen Hinweis auf Datenschutz, sie schließen keinen "Vertrag" ab und die App kostet auch nichts. Nicht dass es auch hier ein abruptes Ende gibt oder die Daten anderweitige "verwertet" werden.

Web und App

Die Anbindung an das Internet hat natürlich für den Kunden erst einmal den werblichen Aspekt, auch auf einem Smartphone (IOS und Android) den Status von überall abfragen zu können. Auf der Webseite sind neben dem Salzverbrauch auch folgende Stammdaten ersichtlich. Wer genau dazu den HTTP-Post betrachtet, kann Übereinstimmungen vieler Felder sehen, die vom LexPlus zur Cloud gesendet werden.

Im Web und der App gibt es noch ein Diagramm zum Satzverbrauch, welches aber wohl auf Daten in der Cloud basiert. Ich habe nicht gesehen, dass historische Daten übertragen wurden. Die hat aber z.B. der LexPlus lokal in seinem Speicher, z.B. Informationen zum Druckerverlauf und den Entnahme-Mengen. Ich bin mal gespannt, ob die Webseite bei Fehlern und Problemen mir eine Mail an die hinterlegte Adresse sendet.

Das Connect Modul ist ziemlich "gesprächig". da es keinen beständigen Rückkanal aufbaut, muss es "pollen", d.h. ca. alle 10 Sekunden fordert es Daten alternierend von zwei Webseiten an und bekommt Antworten zurück, die es auswertet.

Eine Änderung auf der App oder im Web wird dann wohl auf dem Cloud-Service hinterlegt und beim nächsten Connect in der Antwort mit geliefert.

Kommunikation App zur Cloud

Die Abfrage und Anzeige der Daten kann wahlweise über eine IOS oder Android-App erfolgen. Hier kommen mehr Daten an als "nur" ein BMP-Bild. Also habe ich auch hier mich zwischen die App und die Cloud gesetzt um mal zu sehen, was hier passiert. Fiddler als HTTP-Proxy leistet hier sehr gute Dienste und wir sehen auf den ersten Blick schon, dass die APP auch nur HTTP nutzt und neben ein paar Daten als WebServices noch viele Bilder nachlädt.

Die eigentliche "Anmeldung" erfolgt hier bei Paket 32 mit dem Zugriff auf den SyrApiService.Svc. Allerdings fällt auch auf, dass alle Anfragen direkt mit einem "200 OK" beantwortet werden. Stattdessen wird die App wohl direkt die Anmeldedaten abfragen und "blind" mit senden. Im Request sieht man dies aber nicht als Authentication-Header im HTTP-Kopf sondern als Daten eines Form-POST:

POST http://syrconnect.de/WebServices/Api/SyrApiService.svc/REST/GetProjects HTTP/1.1
Host: syrconnect.de
Content-Type: text/xml
Connection: keep-alive
Connection: keep-alive
Accept: */* User-Agent: SYR/29 CFNetwork/808.0.2 Darwin/16.0.0
Content-Length: 288
Accept-Language: de-de
Accept-Encoding: gzip, deflate

<?xml version="1.0" encoding="utf-8"?>
<sc>
   <api version="1.0">xxxxxxxxxxxxxxxxxxxxxxxxxxxxx</api>
</sc>

Ich habe den Code natürlich durch "xxx" ersetzt. Die richtigen Daten sind durch die App wohl zusätzlich "unkenntlich" gemacht, denn der Base64-String wird nach der Decodierung nicht als Benutzer/Kennwort sichtbar. Das kann aber auch einfach nur ein Salt mit einem in der App statisch hinterlegten Information sein. Sicher ist das vermutlich nicht. Dazu müsste eher vom Server eine Information zum Verschlüsseln kommen. Die Antwort liefert dann eben so einen langen Base64 Code:

HTTP/1.1 200 OK
Content-Type: application/xml; charset=utf-8
Server: Microsoft-IIS/8.5
X-Powered-By: ASP.NET
Date: Sun, 09 Oct 2016 11:03:38 GMT
Content-Length: 771

<?xml version="1.0" encoding="utf-8"?>
<sc>
   <api version="1.0">xxxxxxxxxxxxxxxxxxxxxxxxxxxxx=</api>
   <suc v="true"/>
</sc>

Ich habe den Code natürlich durch "xxx" ersetzt

POST http://syrconnect.de/WebServices/SyrControlWebServiceTest2.asmx/GetDeviceCollectionStatus HTTP/1.1
Host: syrconnect.de
Content-Type: application/x-www-form-urlencoded
Connection: keep-alive
Connection: keep-alive
Accept: */* User-Agent: SYR/29 CFNetwork/808.0.2 Darwin/16.0.0
Content-Length: 243
Accept-Language: de-de
Accept-Encoding: gzip, deflate

xml=<?xml version="1.0" encoding="utf-8"?>
   <sc>
      <si v="App-2.23.0-de-DE-iOS-iPhone-10.0.2-de.consoft.syr.connect" />
      <us ug="xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" />
      <col>
         <dcl dclg="yyyyyyyy-yyyy-yyyy-yyyy-yyyyyyyyyyyy" />
      </col>
   <cs v="36AA"/>
</sc>

Der Mitschnitt zeigt die Verbindung einer bereits eingerichtet App. Es kommt also gar kein "404 Access Denied" mit einer nachfolgenden Authentifizierung. Die Anmeldung wird von der App schon beim ersten Request mitgeliefert.

Die ersten vier Anfragen scheinen Informationen von Syr zu laden mit Produkten, News, Hinweisen samt Bilder etc. ehe dann bei Frame 32 die Liste der Projekte geladen wird. Im Request gibt es keine HTTP-Authentifizierung. Stattdessen wird eine XML-Anfrage mit einem BASE64-codierten Binärstring gesendet. Im Frame 45 kommen Details zu den Projekten und für eine Auswertung sind natürlich dann die ab Frame 48 wiederkehrenden Anfragen relevant. Hier erfolgt ein POST auf eine Url mit Anmeldeinformationen im Request und einer umfangreichen Antwort. Hier ein Auszug:

Ich dokumentiere hier natürlich nicht den Request mit meine Anmeldedaten und habe mir auch nicht die Mühe gemacht, die Generierung dieser Informationen zu knacken. Aber jeder Request ist anscheinend "gleich", d.h. es gibt keine laufende oder variable Komponente. Das eröffnet zumindest einen Weg diese Daten per PRTG indirekt über die Cloud abzufragen.

Ein Post auf die URL mit den Daten im Payload liefert eine XML-Datei. Diese kann ich per PRTG:Custom Sensor abfordern, konvertieren und die Werte an PRTG übergeben.

Ich wollte "freundlich" sein und als UserAgent meine Mailadresse hinterlegen aber anscheinend hat der WebService ein "Allowlisting" gültiger Agenten und liefert dann nur eine leere XML. Also muss mein PowerShell-Script sich als IOS App ausgeben.

Eher ich aber nun mit dem PRTG-Sensor anfange, kommt noch eine dritte Kommunikation ins Blickfeld

Firmware Update

Ich wollte ja sicher sein, dass ich mit der aktuellsten Version arbeite. Und tatsächlich gab es für mein frisch installiertes Gerät schon ein Firmware Updates. Das Update durfte natürlich nur mit Überwachung durchgeführt werden. Die Überprüfung auf eine neu Firmware geht über einen dritten Provider (www.husty.pl):

Die URL http://husty.pl/firmware/saocal2/scf.cfg wird natürlich auch wieder unverschlüsselt und ohne Authentifizierung o.ä. aufgerufen. Sie können diese einfach im Browser eingeben und auch die referenzierte Dateien sind einfach per Browser zu laden:

http://husty.pl/firmware/saocal2/scf.cfg
http://husty.pl/firmware/saocal2/slp0_dat.pak
http://husty.pl/firmware/saocal2/slp0.bin

Die pak-Datei ist eigentlich gezippt und kann einfach extrahiert werden. Sie enthält wohl nur Images und Fonts.

Leider gibt es keine HTML, htaccess oder sonstige Dateien, die einen Rückschluss auf eine API erlauben würden. Eine Signatur habe ich nicht gesehen nun wenn in der scf.cfg der letzte Teil in einer Zeile eine Prüfung erlauben sollte, dann ist das ohne SSL-Verschlüsselung auch einfach zu fälschen.

Die BIN-Datei dürfte dann die Firmware sein. Leider sind dort mit einem einfachen Editor erst mal keine Strings o.ä. zu erkennen, die einen Rückschluss auf ein internes Dateiformat o.ä. zulassen.

Zumindest scheint der LexPlus10 nicht selbst nach Updates zu suchen und diese Einzuspielen. Aber nur damit eine "App" funktioniert, sollte man es möglichen Angreifern nicht so einfach machen. Aus der Webseite der App-Entwickler stand dazu:

"Wenn heizungstechnische Geräte mit dem Internet verbunden sein sollen, dann kommt es nicht nur auf die hohe Qualität der Elektronik an, sondern auch auf die Sicherheit der Daten und die Bedienbarkeit"
Quelle: https://www.consoft.de/

Für Geräte der Wasserversorgung würde ich das aber genau so sehen.

Firmware 3.8

Beim Tausch eines undichten Kolbendeckels wurde auch die Firmware aktualisiert. Dies war ratsam, da die Version 3.8 neben einer Wechselbestromung an den Elektroden auch die Wartung beschleunigt. Nach der Reparatur musste nicht erst eine 40 Min-Regeneration abgewartet werden, sondern der Prozess kann beschleunigt werden. Damit habe ich dann natürlich noch mal eine Analyse der Kommunikation durchgeführt. Hier hat sich seit der letzten Analyse was getan

Service Host/IP/URL  

Lex Plus 10 -> Cloud

syrconnect.de (212.77.236.30)  HTTP unverschlüsselt

POST /WebServices/SyrConnectLimexWebService.asmx/GetAllCommands
POST /WebServices/Api/SyrApiService.svc/REST/GetProjects 
POST /WebServices/SyrControlWebServiceTest2.asmx/GetProjectDeviceCollections
POST /WebServices/SyrControlWebServiceTest2.asmx/GetDeviceCollectionStatus
POST /WebServices/SyrConnectLimexWebService.asmx/GetSaltConsumption

Alle 10 Sekunden sendet der Lex Plus 10 einen Request mit wenigen Daten und bekommt meist eine leere Antwort zurück. Hier stehen dann wohl die Befehle, die über die Cloud an den Enthärter gesendet werden.

App zu Web

webservices.syr.de  = 212.77.236.96 ((IIS10  HTTP, kein HTTPS)

POST /DocumentWebService.asmx/GetDocumentOverview
POST /DocumentWebService.asmx/GetDocumentDetails

Die IOS App spricht mit der Gegenstelle. Aber eher Werbung/ProduktInfos

App zu Service

webservices.consoft.de = 212.77.236.99  HTTPS !!!  das scheint nun gesichert zu sein.

Zumindest der Weg von der App zum Service scheint nun verschlüsselt zu sein.

Lex Plus 10 -> Cloud

connect.saocal.pl = 37.187.170.178 (HTTP unverschlüsselt)

POST /GetAllCommands

Anscheinend spricht der Lex Plus 10 immer noch mit einem Server in Polen.

Anscheinend tut sich etwas aber der Weg ist noch lang. Nur weil die App nun wohl per HTTPS mit einem Service kommuniziert, ist der Weg zwischen dem IoT-Gerät und der Cloud noch weit von einer sicheren Umgebung entfernt. Hier noch mal die Kette

  1. Hersteller
    Hier wird das Gerät konstruiert, zusammengebaut und ausgeliefert. Allerdings machen heute nicht mehr alle Hersteller alles selbst und daher gibt es auch Zulieferer und bestimmte Tätigkeiten werden auch gerne in günstigere Länder ausgelagert.
  2. Handwerker
    Der normale "Gas/Wasser"-Installateur kauft die Geräte über den Großhandel und installiert Sie beim Kunden
  3. Kunde
    Die Funktion einer Wasserenthärtung ist sehr schnell in den Perlatoren am Hahn oder den fehlenden Kalkflecken auf Kacheln und Duschwänden zu bemerken. Der immer gerne zitierte "Woman Acceptance Factor (WAF)", mit dem wir IoT-Bastler oft zu kämpfen haben, steigt.
  4. Smartphone
    Wie schön, dass es auch eine App für das Gerät gibt, so dass der moderne Mensch direkt informiert wird, wenn sich der Salz-Stand reduziert oder andere Störungen vorliegen. Die App wird aber nicht direkt vom Hersteller sondern einem Softwarehaus (Consoft) in Hannover angeboten.
  5. Cloud Service als Brücke in Polen  (husty.pl)
    Da weder das IoT-Gerät noch das SmartPhone eine direkte Verbindung zueinander aufbauen können, muss ein Service in der Cloud herhalten. In dem Beispiel läuft er bei einem Großhändlerin Polen. Offiziell kenne ich weder den Großhändler noch gibt es einen Vertrag oder gar eine Datenschutzvereinbarung. Die Megabytes pro Monat aufgrund der ineffektiven Kommunikation kostet aber Geld.
  6. Firmware aus Osteuropa ?
    Dann habe ich immer mal wieder "Kontakte" zu einem Server in Tschechien gesehen. der wohl auch Firmware-Updates bereit stellt.

Es bleibt also dabei: Der Lex Plus 10 darf zwar ins LAN aber nicht ins Internet. Er funktioniert nämlich auch ganz ohne Internet.

Firmware 4.1

Anfang Januar 2021 habe ich ein Update der Firmware auf Version 4.1 vorgenommen. Ich habe dazu temporäre das IoT-Netzwerk nach extern geöffnet, so dass der Wasserenthärter sein Update finden und installieren konnte. Im Netzwerkmenü gibt es den Firmware-Button, um das Update anzustoßen.

Der ganze Prozess hat weniger als 2 Minuten gedauert. Aber leider hat ein Check der Ports (nmap) keine neue Ports aufgezeigt. Der Zugang per HTTP liefert weiterhin nur ein Screencapture der aktuellen Anzeige.

Eine schnelle Analyse der BIN-Datei mit "Binwalk" hat leider keinerlei bekanntes Format ermittelt. Es dürfte sich also nicht um eine Linuxoides Image o.ä. handeln, sondern reiner Maschinencode für den Prozessor. "Sichtbar" ist im Code nicht wirklich etwas. Es muss ja nicht mal ASCII/ANSI sein. Selbst BigEndian/LittleEndian könnten den Einblick erschweren.

Offen und Wünsche

Die Installation durch den Handwerker war relativ problemlos und das weichere Wasser macht sich beim Duschen, Waschen aber auch Putzen (keine Kalkschlieren, freie Perlatoren) bemerkbar und ich bin langfristig gespannt, wie sich entsprechend der Waschmittelverbrauch reduziert. Bezüglich der "Wassertechnik" habe ich nichts auszusetzen, zumal diese Funktionen auch alle ohne Cloud funktionieren. Aber technologisch wäre noch viel mehr drin oder müsste auf jeden Fall etwas sein:

  • Lokaler Service
    Der LexPlus hat einen kleinen WebServer, der aktuell nur das angezeigte Bild liefert. Es kann doch nicht so schwer sein, über eigene URLs auch die Daten zu liefert, die der Lex so an die Cloud sendet. Für Anwender könnte es auch reichen, denn die Buttons "klickbar" wären und damit das Display quasi "fernsteuerbar" sind. Mit einem 70€ Tablet könnte man sich eine "Fernkonsole" bauen. Für eine Abfrage der Daten aus dem lokalen LAN ist natürlich eine XML, SOAP, JSON-Antwort eleganter zur Einbindung in eigene Projekte. Die Diagramme könnte man einfach als CSV-Dateien abrufbar machen.
    Für den Anfang würde es mir schon mal reichen, die Gesamtanzahl der enthärteten Liter Wasser als Counter zu haben. Ähnlich einem LAN-Port könnte PRTG oder eine andere Lösung schon einfach die Differenz zur vorherigen Messung erstellen und damit einen Momentan-Verbrauch ermitteln.
  • Leckage-Schutz
    Weder über die Webseite noch die Cloud Services sind die Daten erreichbar, die direkt am Gerät auszulesen sind. Dabei erfasst das System schon neben dem Wasserdruck auch die Verbrauchswerte inklusive aktuellem Verbrauch. Syr stellt mit dem Safe-T Connect auch einen Leckage-System her. Genaugenommen könnte dies aber auch der LexPlus selbst und z.B. per Schaltausgang ein Magnetventil schließen, wenn zu lange kontinuierlich das Wasser läuft (Thema Schlauch geplatzt). Laut Anzeige hat er eine sehr genaue Momentanverbrauchsmessung.
    Mit einem Magnetventil im Zulauf und etwas Software wäre beides in einem Gerät möglich und sogar bei Salzmangel könnte das Wasser abgestellt werden.
  • App-Anmeldung
    Es ist mir nicht gelungen in der App ein Syr-Connect Konto anzulegen. Fehler ist hier, dass die App nur ein Kennwort mit 5 oder mehr Buchstaben erzwingt, die Webseite mittlerweile aber 8 Zeichen erwartet. Das ist aber eher ein kosmetischer Fehler, der einfach abzustellen wäre.
  • Portal:/App: Vertrags- und Datenschutz-Fragen
    Die Anmeldung im Portal geht schnell aber ohne jeglichen sichtbaren Hinweis einher, welche Leistungen Syr hier zusichert. Insbesondere wie lange der Service mit welchen Randbedingungen bereit gestellt wird. Wer hat z.B. Zugriff auf die Daten, wo werden die Daten gelagert etc. Eine ganz profane Datenschutzerklärung habe ich nicht gesehen.
  • Portal Adressdaten
    Bei der Registrierung kann man auch die Adresse angeben. Diese wird aber nicht mit bei der ersten Anlage übernommen. Ich kann verstehen, dass die "Kontodaten" von der "Anlage" getrennt sind, aber bei den meisten Anwendern wird es ja wohl die gleiche Information sein.
  • Web Portal: Abmeldung
    Ich habe auf der Webseite keinen Button zum "Abmelden" gefunden. Und wir nicht anders zu erwarten konnte ich das Fenster im Browser schließen und auch wieder öffnen und war wieder drin. Erst ein komplettes Schließen aller Browserfenster hat die erneute Anmeldung erforderlich gemacht.
  • Steuerung per Internet ohne Verschlüsselung ?
    Die Fernsteuerung erfolgt derart, dass der Client Änderungen auf einem Server hinterlegt, die der LexPlus beim nächsten Polling (20Sek) abholt und umsetzt. All das erfolgt ohne weitere Authentifizierung zwischen App/Browser und Gerät. Jeder, der also auf eine Abfrage eine Antwort sendet, könnte z.B. die Rohwasserhärte, den Salzvorat und die Regenerationszeit umstellen.

Das sind mir schon sehr viele "offene Punkte", die mich wirklich daran zweifeln lassen, dass eine Internet-Anbindung eines Wasser-Enthärters wirklich eine gut Idee sein soll. Würde Syr auf den Computer eine kleine minimalistische Webseite aufsetzen, die auch aus dem internen LAN abfragbar ist und in andere Haus-Automatisierungssysteme integriert werden könnte, wäre das was anderes. So aber verzichte ich lieber auf die "App-Anbindung" und laufe ab und an in den Keller. Denn ohne Internet kann die Box keine Mail senden und einen Schaltkontakt für "Salzmangel" oder "Überlauf" oder andere Störungen gibt es leider nicht.

Ich kann nur hoffen, dass eine zukünftige Firmware hier mehr Sicherheit und lokale Zugriffe erlaubt. Ansonsten bleibt der Netzwerkstecker abgezogen.

Nur gut dass die eigentlich Enthärterfunktion des Geräts auch komplett ohne Cloud funktioniert.

Weitere Planung

Wenn es von Syr keine API gibt, dann kann ich eigentlich nur "Cloud" simulieren. Die Box verbindet sich ja mit "http://syrconnect.consoft.de/WebServices/SyrConnectLimexWebService.asmx/GetAllCommands" und es hindert mich ja niemand daran, der Lex10 als DNS-Server statt dem DSL-Router einfach den DNS-Server auf meinem NAS zu geben. Der liefert dann statt der öffentlichen IP-Adresse "212.77.236.30" einfach eine private Adresse aus, an die die LEx10 ihren Request sendet. Dort muss ich dann nur noch z.B. ein PowerShell-Script oder eine ASPX-Seite laufen lassen, die die Daten annimmt und bei Bedarf wieder an meine Hausautomatisierung herausrückt. Über die Webseite mit einem GIF-Bild wollte ich nicht gehen.

Oder ich nutze die Funktionen meines lokalen Web-Servers auf meinem Synology DS216j-NASs oder doch einen RasPi, der "die Syr-Cloud" quasi nachbaut, damit der Wasserenthärter seine Daten abliefert.

Auf https://www.openhab.org/addons/bindings/oceanic/ wird aber auch die Anbindung an OpenHAB über einen seriellen CAN-Bus beschrieben.

Schade, dass die Entwickler der Software hier nur an ihre Cloud gedacht haben und jegliche, selbst triviale, Schnittselle für eigene Anbindungen vergessen haben. Ich erwarte ja gar keine REST-API mit HTTPS und OAUTH. Aber ein "ReadOnly"-Zugriffe auf allgemeinen Betriebsparameter sollte sich doch leichter realisieren lassen, als ein "Screencapture" des Bildschirms.

Weitere Links