PRTG und Syr LexPlus 10

Mit einer Härte von 14 dH ist das Wasser in Hövelhof schon ziemlich kalkhaltig und Chromamaturen 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. Für PRTG ist natürlich interessant, dass die Anlage einen Ethernet-Anschluss eingebaut hat. Ich habe in weiser Voraussicht schon CAT5-Anschlüsse in den Hausanschlussraum gelegt. Dort kommt ja auch DSL an.

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.

Kommunikation Lex-Plus zur Cloud

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.

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 5Megabyte/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 "Whitelisting" 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

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):

Alles natürlich weiter unverschlüsselt und ohne Authentifizierung o.ä. Ich kann nur hoffen, dass die beiden Dateien mit 649kB und 2971kB intern irgendwie signiert sind. Ich habe aber nicht gesehen, dass der LexPlus10 das Update alleine durchgeführt hat. Die größere Datei ist ein ZIP-Archiv mit Audio-Dateien und Fonts. die kleinere Firmware errät zumindest auf den ersten Blick keine weiteren interessanten URLs des eingebauten Webservers. Nur damit eine "App" funktioniert, sollte man es möglichen Angreifern nicht so einfach machen.

"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.

Einfacher Sensor mit PRTG

Mein Ziel war es ja, bestimmte Daten in meine PRTG-Überwachung zu übernehmen. In der ersten Version nutze ich einfach die Cloud-Dienste und geben mich als IOPS-App aus. Die Zugangsdaten scheinen sich nicht zu ändern und alle 5 Minuten ein Anruf sollte mir ausreichen um z.B.: eine Information über Salzmangel zu bekommen. Wobei man wissen muss, das der LexPlus keinen echten Mangelsensor hat, sondern anhand des Verbrauchst bei seiner Regenerationen und der nach dem Einfüllen eingegebenen Salzmenge im Behälter errechnet, ob es reicht.

Ich habe mir aus Fiddler oder Wireshark einfach den Request ausgelesen, den die App an SyrConnect sendet, diesen Abruf per Powershell durchgeführt und die Ausgabe für PRTG umformatiert. Eigentlich ein ganz einfaches PowerShell-Script, welches PRTG nun einmal alle 5 Minuten aufruft.

# PRTG-SyrLexPlus
#
# Grabbing data from the SyrConnect Service to viaualize in my own monitoring
# You have to caputre the authentication XML manually from a IOS/Anroid-App with Fiddler, Wireshark or similar

$url = "http://syrconnect.de/WebServices/SyrControlWebServiceTest2.asmx/GetDeviceCollectionStatus"
$formFields = @{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="xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" />
                        </col>
                        <cs v="36AA"/>
                     </sc>'}
try {
   $postresult = Invoke-RestMethod `
                    -Uri $Url `
                    -Method POST `
                    -ContentType "application/x-www-form-urlencoded"`
                    -Body $formFields
}
catch {
   write-error "Error during retrieving data"
}

[hastable]$resulthash=@{}
if ($postresult) {
   foreach ($node in $postresult.sc.dvs.d.c){
      if ($node.v  -ne "") {
         $resulthash[$node.n]=$node.v
      }
      elseif ($node.dt  -ne "") {
         $resulthash[$node.n]=$node.dt
      }
      else{
         $resulthash[$node.n]=""
      }
   }
}
#$resulthash


$prtgresult = '<?xml version="1.0" encoding="UTF-8" ?>
<prtg>
   <result>
      <channel>Salzvorrat (SS1) Wochen</channel>
      <value>'+$resulthash["getSS1"]+'</value>
      <float>1</float>
   </result>
   <result>
      <channel>Restkapazitaet (RES) Liter</channel>
      <value>'+$resulthash["getRES"]+'</value>
      <float>1</float>
   </result>   
   <result>
      <channel>Weichwasserhaerte (IWH) dH</channel>
      <value>'+$resulthash["getIWH"]+'</value>
      <float>1</float>
   </result>
   <result>
      <channel>Rohwasserhaerte (OWH) dH</channel>
      <value>'+$resulthash["getOWH"]+'</value>
      <float>1</float>
   </result>
   <result>
      <channel>Wasserdruck (PRS) bar</channel>
      <value>'+$resulthash["getPRS"]/10+'</value>
      <float>1</float>
   </result>
</prtg>'

$prtgresult

Diese PS1-Datei legen Sie dann wieder in "C:\Program Files (x86)\PRTG Network Monitor\Custom Sensors\EXEXML" ihres PRTG-Servers ab und pflegen die richtigen Werte für das POST ein.

Dann können Sie das Script als EXE/Advanced wieder gemäß der Anleitung auf PRTG:Custom Sensor einbinden. Ein Aufruf alle Minute ist sicher zu häufig und belastet den PRTG-Server ohne Mehrwert. Ich habe nur eine überschaubare Anzahl an Sensoren und lasse ihn all 5 Minuten abfragen. Nach der ersten Messung hat PRTG auch die Kanäle gelernt und sie können Alarme einrichten.

Ich habe mir eine Warnung für den Salzvorrat eingerichtet, wenn er auf unter 2 Woche kommt.

Bei meinem aktuellen Verbraucht hält ein 25kg Sack ca. 15-20 Wochen und dank dem Status in PRTG, der Mail verpasse ich das nicht mehr und in die PRTG Mobile App ist der Sensor ebenso integriert. Parallel gibt es natürlich auch noch den einfachen ICMP-Sensor um die Erreichbarkeit zu prüfen.

Der HTTP-Sensor kann zwar genutzt werden, um den kleinen Webserver mit dem BMP-Bild zu prüfen aber ich habe eigentlich nicht vor darauf noch eine OCR-Erkennung zu machen, um weitere Daten wie z.B. die Durchflussmenge zu ermitteln. Da hoffe ich eher drauf, dass die Daten irgendwann doch mal anders abgerufen werden können

Es bleibt natürlich noch die Frage, was die sonstigen Werte der 50 gemeldeten Felder sonst alles bedeuten, die ich nicht zuordnen kann und in der App auch nicht angezeigt werden. Hier mal ein Auszug:

PS C:\temp\prtgsensoren> $postresult.sc.dvs.d.c

n                          v                          dt
-                          -                          --
getSRN                     161308410                  06.10.2016 07:18:33
getCNA                     LEXplus10
getDEN                     1
getMAC                     xx:xx:xx:x:xx:xx  (Die MAC-Adresse habe ich entfernt und ist für PRTG nicht nutzbar)
getSTA
getMAN                     Syr
getALM                                                06.10.2016 06:24:06
getCDE                     010SCA19DF0917.01.024.1...
getCS1                     83
getCS2                     0
getCS3                     0
getCYN                     0
getCYT                     00:00
getDWF                     200
getFCO                     0
getFIR                     SLP0
getFLO                     0
getNOT
getPA1                     0
getPA2                     0
getPA3                     0
getPRS                     49
getPST                     0
getRDO                     80
getRES                     2288
getRG1                     0
getRG2                     0
getRG3                     0
getRPD                     4
getRPW                     0
getRTI                     00:00
getSCR                     0
getSRE                     0
getSS1                     16
getSS2                     0
getSS3                     0
getSV1                     22
getSV2                     0
getSV3                     0
getWHU                     0
getTOR                     3
getVER                     LEX Plus V3.0
getVS1                     0
getVS2                     0
getVS3                     0
getOWH                     6
getRTH                     1
getRTM                     0
getIWH                     14
getTYP                     80

Auf dem Display gibt es mehr

Leder sehe ich hier in keinster Weise die Werte, die auf dem Display selbst sehr wohl angezeigt werden können wie z.B. die Verbräuche. Hier mal ein paar Bilder:

Leider habe ich noch keinen Wert gefunden, der zumindest die pro Stunde, Tag, Montag und Jahr kumulierten Werte bereit stellt, um diese Grafiken in PRTG zu erzeugen. Mir würde ja schon eine kleine XML/JSON/CSV-Ausgabe reichen, die man vom Webserver abrufen kann.

PRTG als SyrConnect Backend

So schön eine "offene Kommunikation" für die Untersuchung ist, so ungern mag ich, dass mein System mit Cloud-Diensten spricht. Viel lieber wäre mir, wenn ich lokal die Daten einfach per Browser, Rest-API, SNMP o.ä. abfragen kann, wie ich das bei PRTG:Kostal oder PRTG:Pluggit gemacht habe. Aktuell noch nicht umgesetzt aber in der Planung ist daher ein Umbau in der Art, dass der LexPlus nur noch "denkt" er würde mit dem Internet sprechen aber in Wirklichkeit mit dem PRTG-Server spricht. Dazu muss ich natürlich einige Einstellungen vornehmen

  • Zugang zum Internet blocken
    Das geht in der Fritz!Box recht einfach, indem ich die IP das passende Profil zuweise. Zudem kann ich den LexPlus von DHCP auf manuell konfigurierte IP-Adressen einstellen und dabei z.B. das Default Gateway untauglich machen.
  • Interner DNS umleiten
    Die Namensauflösung für connect.saocal.pl und syrconnect.consoft.de leite ich über den eigenen DNS-Service auf einen lokale IP-Adresse um. Dazu stelle ich den LexPlus von DHCP auf statische IPs um und trage meinen internen DNS-Server ein, der natürlich Anfragen auch nach extern weiterleitet. Aber ich kann dann mit Stub-Zonen die Anfragen abfragen und auf meinen "WebServer" umleiten.
  • Eigener HTTP-Service
    Auf dem PRTG-Server räume ich Port 80 frei und starte dort meinen eigenen WebServer, der die Anfragen annimmt und verarbeitet. Ich bin noch nicht sicher, ob ich das wieder per PowerShell mache oder doch mal eine ASPX-Applikation für den IIS schreibe.

Leider liefert LexPlus nur Momentan-Werte. Andererseits kann PRTG dieses ja auch selbst in eine historische Datenbank ablegen. Damit PRTG den Port 80 nicht für eine Umleitung verwendet, muss folgender Eintrag in der Registrierung addiert und der Dienst durchgestartet werden:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Paessler\PRTG Network Monitor\Server\Webserver]
"NoSSLRedirect"=dword:00000001

Mit PRTG abfangen

Aktuell ist dieser Teil noch eine Baustelle, da die Nutzung der Cloud aktuell noch aktiv ist. Ich spekuliere auch darauf, dass Syr vielleicht ihre Firmware dahingehend erweitert, dass direkte Abfragen per HTTP-GET/POST lokal möglich sind.

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 Momentanverbrauch 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 Links