Hallo ma7ja5,

nun dass die Zugangsdaten für das Portal hinterlegt sein müssen ist ja logisch ansonsten kommt der SolarLog auch nicht auf dein Portal drauf. Auch die Konfigdatei ist wichtig, da aus dieser im Portal verschiedene Berechnungen gemacht werden und auch die Option bei größeren Anlagen besteht die Anlagenkonfiguration im SolarLog über eine Remotefunktion zu ändern (Wichtig für Solarteure).
Auch gibt es private Tools, mit denen du die Konfiguration ändern kannst, ohne direkten Zugriff auf den SolarLog haben zu müssen, was sehr nützlich ist wenn sich die Anlage nicht am Wohnort befindet. Somit ist die Übertragung schon sinnvoll.

Für deine Mails frage ich mich allerdings warum du hier deinen privaten E-Mail Zugang einträgst. Solare Datensysteme liefert dir hier eine eigene Mailadresse mit, die die gleichen Zugangsdaten hat wie deine SolarWeb-Anmeldung. Unter Konfiguration//Erweitert//EMail trägst du unter dem Eintrag "Mail-Adresse Von" die Mailadresse ein, die du von SDS bekommen hast z.B. "meinbenutzername@home2.solarlog-web.de". Im Feld "Mail-Adresse Nach" gibst du dann nur die reine Mailadresse an, an die du die Mails gesendet haben willst. Hier benötigst du dann keine Zugangsdaten deines privaten Mailservers.
Du bekommst dann alle Mails an diese Adresse gesendet. Sicherlich im ersten Moment von SDS nicht perfekt gelöst, da man bei anderen Loggerherstellern einfach nur seine Mailadresse eingeben muss, aber im Hintergrund ist auch hier der Umweg über das Mail-Portal des Loggerherstellers eingetragen. Somit bist du beim SolarLog sogar noch flexibler, da du hier den Mailprovider noch selbst eintragen kannst (z.B. bei der Nutzung eines eigenen Portals).

Alle anderen Benutzerdaten hat SDS dir ja gegeben, somit hätten sie diese ja schon falls sie was böses im Schilde führen wollten. Sofern du deinen Router nicht freigibst kann auch von aussen kein Zugriff auf deinen SolarLog erfolgen. Da auch das Passwort von SDS nicht freivergeben werden kann, besteht somit auch nicht die Gefahr, dass ein User sein Stammpasswort, dass er für alle Applikationen verwendet (gibt viele die das tun), hier eintragen kann. Somit sind die Daten hier nur für SDS und dich relevant.
Auch hast du in deinem Beitrag recht, dass es noch ein paar Hintertürchen gibt mit denen SDS zu Diagnosezwecken auch direkt auf deinen SolarLog zugreifen kann. Hat vielen Usern schon geholfen, da Fehler direkt von der Entwicklung analysiert und behoben werden konnten. Allerdings musst du dazu auch die in der SolarLog-Anleitung angegebenen Ports im Router freischalten. Somit bestimmst du allein auf was SDS zugreifen kann oder nicht.

Wenn du hier zu SDS kein Vertrauen hast, dann solltest du deine Daten auf einem eigenen Server ablegen. SDS stellt dir dazu auch kostenfrei eine Software zur Verfügung z.B. "Solar-Log™ WEB „Self Made“" siehe hier: http://www.solar-log.com/de/produkte-lo ... eiber.html


Viele Grüße
Wolfgang

Ich stimme Wolfgang vollkommen zu.

Wenn Du nicht willst, dass deine Daten an SDS Übertragen werden, dann nutze deinen eigenen Server, der am besten bei Dir zuHause steht - sonst haben die Daten ja dein Server-Hoster

Zudem gibts bei SDS bis 30kWp das ganze kostenlos inkl. des Mailaccounts, da braucht man nicht seine eigenen Mail-Accounts verwenden....

Für uns SolarLog-fans bringts jedenfalls den Vorteil eine Fernkonfiguration vorzunehmen wodurch wir uns teilweise sehr viel Geld und Zeit sparen.


Grüße, Maggi

Wolfgang Neumann hat geschrieben:Hallo ma7ja5,

...

Für deine Mails frage ich mich allerdings warum du hier deinen privaten E-Mail Zugang einträgst. Solare Datensysteme liefert dir hier eine eigene Mailadresse mit, die die gleichen Zugangsdaten hat wie deine SolarWeb-Anmeldung. Unter Konfiguration//Erweitert//EMail trägst du unter dem Eintrag "Mail-Adresse Von" die Mailadresse ein, die du von SDS bekommen hast z.B. "meinbenutzername@home2.solarlog-web.de". Im Feld "Mail-Adresse Nach" gibst du dann nur die reine Mailadresse an, an die du die Mails gesendet haben willst. Hier benötigst du dann keine Zugangsdaten deines privaten Mailservers.
Du bekommst dann alle Mails an diese Adresse gesendet. Sicherlich im ersten Moment von SDS nicht perfekt gelöst, da man bei anderen Loggerherstellern einfach nur seine Mailadresse eingeben muss, aber im Hintergrund ist auch hier der Umweg über das Mail-Portal des Loggerherstellers eingetragen. Somit bist du beim SolarLog sogar noch flexibler, da du hier den Mailprovider noch selbst eintragen kannst (z.B. bei der Nutzung eines eigenen Portals).

...
Viele Grüße
Wolfgang

Hallo Wolfgang,
ich habe meinen private e-mail-adresse eingetragen, weil es in der Dokumentation nirgendwo erwähnt ist, dass man es nicht machen soll.
Genauso wenig wie erwähnt ist, dass zusätzlich zu den (dokumentierten) Ertragsdaten auch die Konfigurationsdaten übertragen werden.
Übrigens wird auch das Systempasswort übertragen. Also alle Solar-Logs die direkt im Internet hängen und nur über diese Passwort geschützt werden sind damit offen.

Mein Wunsch an die Hersteller: Dokumentiert was ihr übertragt in der Benutzerdokumentation und gebt dem Benutzer die Wahl ob er die Daten übertragen haben will oder nicht.

Solange die Hersteller diese Transparenz nicht liefern, sollte man etwas Vorsicht walten lassen. Es könnte ja sein, dass außer der Passwortübertragung noch andere Funktionen enthalten sind, mit denen man sich eine Back-Door einfangen kann. Speziell in Firmennetzen sehe ich den Solar-Log daher als kritisch an.

Gruß

Hallo ma7ja5,

Also ich sehe dass ganze Thema hier als eher unkritisch....denn wenn man wirklich befürchtet sich da etwasmeinzufangen, dann darf ich halt auch nur die vom Solarlog genutztenPorts offen lassen...diese beschraenken sich ja auf den sftp und FTP Port!
Und wg des Passwortes nochmal...du loggst dich wahrscheinlich auf deinem FTP ganz normal ein-da wird das Passwort auch übertragen und sogar unverschluesselt....die fragen auch nicht vorher ob du möchtest dass das so gemacht wird!
Beim SL ist es immerhin verschlüsselt...und eine direkte Verbindung hast du ja zum SL eh nicht aus dem Internet außer du hast DynDns eingerichtet wodurch sich schon wieder eine Frage der Sicherheit stellt....
Also was bringen dir dann die Zugangsdaten, wenn du eh keinen Zugriff auf den Logger hast?
Du kannst nicht mal oder im schlimmsten Fall den SolarLog die Übertragung abgewöhnen....das war's aber auch schon....


Schöne Gruesse,
maggi

ma7ja5 hat geschrieben:Hallo Wolfgang,
ich habe meinen private e-mail-adresse eingetragen, weil es in der Dokumentation nirgendwo erwähnt ist, dass man es nicht machen soll.

Hallo ma7ja5,

da muss ich dir wiedersprechen, mit der Mail steht dies einmal in der Anleitung und zum anderen auch in der Nachricht deiner Zugangsdaten, dass du nicht deinen privaten Mailaccount nutzen musst sondern vom SDS einen eigenen Mailzugang bekommst. Du musst also wie oben beschrieben nur deine Mailadresse eintragen um Mails zu bekommen nicht deine eigenen Zugangsdaten.


Was die anderen Punkt angeht, so habe ich dir versucht die Gründe der Übertragung zu erklären. Zu dem Nutzen für die Allgemeinheit habe ich dir was im anderen Beitrag zum gleichen Thema geschrieben: datenlogger-f5/welche-daten-uebertragen-eure-datenlogger--t72167.html.

Es ist nicht gerade glücklich das es hier zwei Beiträge zum gleichen Thema gibt in denen diskutiert wird, zumal die Probleme doch sehr SolarLog spezifisch sind.

Was deine Kritik an SDS bezüglich der Dokumentation angeht, so hast du soweit Recht, das hier ein Hinweis noch besser ausfallen könnte - allerdings muss ich dir ehrlich gestehen, dass ich mir die AGB´s zur Nutzung des Portals nicht ganz durchgelesen habe - vielleicht steht da ja was zur Datenübertragung und Datennutzung drin. Werde mal bei Gelegenheit dort reinschauen - dann kann man ggf. falls notwendig immer noch SDS informieren, hier gemäß BDSG den Kunden besser zu informieren. Hast du sie schon gelesen?

Allgemeine AGB´s: http://www.solar-log.com/fileadmin/BENU ... eutsch.pdf

AGB´s zum alten Portal SolarLog-Home: http://www.solarlog-home.de unter AGB

AGB´s zum neuen Portal SolarLog- Web: http://home2.solarlog-web.de/terms.html und die Datenschutzrichtlinie: http://home2.solarlog-web.de/privacy.html

Wenn dir diese Texte und Zusicherungen nicht ausreichen und du weiterhin kein Vertrauen zu SDS und zum SolarLog hast - dann solltest du dir wie schon beschrieben, über die SolarLog-Selfmade Software die Daten nur noch auf deinem PC erfassen und den Zugang vom SolarLog nach aussen auch komplett durch deinen Router sperren, so dass auch evt. geheime von SDS versteckte Programme im SolarLog keine Türchen öffnen können oder doch Zugangsdaten nach aussen geben.

Viele Grüße
Wolfgang

Hallo Wolfgang,
ich habe das Solar-Log Produkt (den SolarLog200) gekauft. Daher muss ich formal weder diese AGB kennen, noch sind sie irgendwie bindend. Dies wird es erst, wenn ich das SolarWeb verwende und diesen AGBs zustimme. Ich kann jedem nur empfehlen dies nicht zu tun.
Es gibt genügend SolarLog Anwender die z.B. das sonnenertrag.eu Portal verwenden. Sie tun dies guten Gewissens, da sie gemäß SolarLog Dokumentation ja nur ihre "Ertragsdaten" übertragen.
Sie wissen nicht, dass dabei Konfigurationsdaten, Passwörter und eventuell sogar Stromverbrauchsdaten (falls der S0 entsprechend verwendet wird) veröffentlicht werden.
Eine solide Firma, die das Datenschutzgesetz und die Kundeninteressen ernst nimmt, würde in der Dokumentation dieses Verhalten beschreiben und dem User die Wahl lassen, was er übertragen haben will.
Die Solaren Daten Sauger wollen das Thema anscheinend aus sitzen. Das Risiko, dass einige User ihnen nicht mehr alle Daten zukommen lassen (wenn die User nicht mehr alles übertragen haben wollen) scheint den Herren an den Geldbeutel zu gehen.
Ich warte zumindest auf ein Update der Dokumentation.

Schöne Weihnachten

Hallo ma7ja5 und alle anderen,

ja, was da bei SDS auf den Servern liegt, kann man ggf. als "kritisch" einstufen. Die Passwortverschlüsselung ist relativ einfach, wenn man weiß wie. Dass die Passwörter nicht in der base_vars.js liegen, sondern in der Config_XXXXX.dat spielt dabei keine Rolle. Hier wurde auch erwähnt, dass die Config_XXXXX.dat auch zufällig ist. Das ist natürlich nur wieder Halbwissen. Habe ich Zugriff auf die base_vars.js, habe ich auf alles Zugriff, denn daraus lässt sich alles ableiten.

Selbst das Homepagekit hilft da nicht, sofern man dies bei sich lokal auf dem Server hat und wieder als z.B. iFrame in eine bestehende Seite im Web einbindet. Ausser man konfiguriert seinen eigenen Webserver entsprechend, was aber zu Problemen in der Darstellung führen kann. Es würde einzig helfen, den Server wirklich nur lokal ohne Anschluss ans Internet zu betreiben. Dann geht aber z.B. keine Fernabfrage. Das SL App für iPhone würde übrigens noch funktionieren, wenn man die entsprechenden Daten bei der Erzeugung kopiert ohne dabei die Systemrelevanten in's Netz zu stellen. Aber das ist ein anderes Thema.

Irgendwer hat geschrieben "Wer macht sich die Mühe und hackt den Solarlog?": Hacken ist ein Wort, dass immer missbräuchlich verwendet wird. Bitte tut mir einen Gefallen und benutzt dieses Wort nicht einfach so, sondern macht euch mal schlau über Begriffe wie hacken, cracken und Skriptkiddies. Es gibt übrigens genug Leute, die den Solarlog analysieren. Ich gehöre auch mit dazu und ich behaupte auch mal, dass mein Wissen um den Solarlog mittlerweile so groß ist, dass ich genug damit machen könnte.

Wie hier aber schon erwähnt wurde, und das richtet sich an ma7ja5, ist es richtig, dass es nicht in der Doku erwähnt wird. Jedoch erhältst Du ja eine eigene Email + Passwort von SDS für Deinen SL. Somit kann das Risiko vermindert werden, wenn man nur diese Daten benutzt, dass man an Deine "normalen" Daten kommt, da ja weder Email noch Passwort (sofern nicht auf ein StandardPW geändert) in einem unmittelbaren Zusammenhang mit Dir gebracht werden können. Schön ist es aber prinzipiell nicht, da gebe ich Dir recht, dass sowas so gespeichert wird.

Ich programmiere derzeit ein eigenes SL Portal, mit erweitertem Funktionsumfang als das normale Web 2nd Classic und Commercial Web zusammen. Auch eine Fernkonfiguration wird möglich sein wie bei SDS im Commercial Web (ist eine Art erweitertes Solarlog Portal mit mehr Möglichkeiten wie eben z.B. Überwachung und Konfiguration). Auch auf meinem Server landet (zwangsläufig) die base_vars.js und config_XXXX.dat, jedoch werden diese entgegen genommen und gelöscht (im Falle der base_vars.js) bzw. verschlüsselt (Kombination aus Salt, einem PW von mir und Teilen des PW des Kunden als MD5 Hash) in der Datenbank abgelegt und dann gelöscht von der Platte (im Falle der config_XXXX.dat). Natürlich habe ich dann Zugriff auf die config_XXXXXX.dat, und das muss ich auch für Fernkonfiguration, um eine config_portal_XXXX.dat schreiben zu können. Das ist übrigens der Grund, warum die Daten auch bei SDS rumliegen. Sie benötigen diese einfach.

Es ist nur eine Frage der Zugriffskonfiguration im Webserver, schon wären viele Probleme behoben.

Aber bisserl Paranoia muss ich Dir schon unterstellen, ma7ja5. Aber keine Angst, das bin ich auch (liegt wohl in der Natur von Admins/Codern^^). Aber dass Du schreibst: "Sie wissen nicht, dass dabei Konfigurationsdaten, Passwörter und eventuell sogar Stromverbrauchsdaten (falls der S0 entsprechend verwendet wird) veröffentlicht werden. " wundert mich. Was wäre sonst der Sinn einer AÜ mit INet Anbindung? Klar, dass Passwörter übertragen werden, ist nicht schön, aber ein nötiges Übel, auch dass Sie bei SDS liegen. Und Stromverbrauch über Internet, ja gut, aber das ist dann so gewünscht. Ich will ja über's Internet meine Daten ansehen können usw. Da würde nur wieder eigenes Homepagekit mit entsprechend konfigurierter .htaccess (im Falle von Apache) oder entsprechender Konfig eines nginx helfen.

Was mich persönlich aufregt, ist, dass SDS Sachen wie SFTP oder eine HTTPS Übertragung usw nicht unterstützt. Auch das wirklich nicht optimal gelungene Dateisystem für die Auswertung und noch viel schlimmer, die Inkonsistenzen zwischen min_, day, month und years, die ich hier etliche male bei Kunden habe und bei denen SDS einfach nur die Achseln zuckt. Aber vieles ist leider einfach historisch gewachsen und lässt sich so einfach nicht mehr ändern. Ein komplettes Code-Redesign wäre aber angebracht und diese neue Firmware müsste dann mit einer geänderten Version des Solarlog 2nd Web Edition arbeiten. Aber sowas kostet Zeit und Geld und ist nichts, was man so eben mal macht. Ich code seit ca. 6 Monate an meinem Portal und bin noch nicht fertig.

Gruß
Micha