Sunny Tripower 6000TL-20

appi · 11 Mai 2016, 21:33:18

Hallo
Fehler bezüglich Absturz von Fhem selber gefunden. Im Log steht:
Can't locate object method "new" via package "DateTime" (perhaps you forgot to load "DateTime"?)

Lösung aus dem Forum:
"use DateTime;" wird übrigens nicht installiert, sondern in die 99_myUtils.pm geschrieben. Davor muss diese Modul natürlich auf Betriebssystemebene installiert sein

nun läuft die PV Anlage und die Implementation in FHEM.

gruss Remo

Waldmensch · 11 Mai 2016, 22:31:23

Okay, das müsste dann oben ins Modul. Mach ich, wenn ich aus dem Urlaub zurück bin. Vermutlich funktioniert es bei mir, weil schon irgend ein anderes Modul DateTime benutzt.

Volker Kettenbach · 14 Mai 2016, 12:59:17

Hallo SpenZerX,
hallo Waldmensch,

ich habe mir heute noch mal abschliessend das Kommunikationsverhalten meiner drei Speedwiregerät angeschaut und dafür am Switch, an dem der SHM hängt, einen Monitorport geschaltet und Traffic dorthin gedumpt. Eine Analyse mit Wireshark hat bestätigt, dass

- das SMAEM komplett per Multicast kommuniziert (außer natürlich dessen Weboberfläche)
- der STP zwar per Multicast vom SHM im Netzwerk gefunden wird, aber dann per Unicast vom SHM abgefragt wird.

Das Auffinden eines Gerätes per Multicast implementiert mein Python-Skript discover.py in u.g. Repository. Denkbar wäre auch eine Implementation im Perl-Modul für FHEM, so dass das FHEM-Modul alle STPs im Netz selbst findet. Leider gibt es aber in Perl scheinbar keine Implementation des Reactor-Patterns, wie es Sie in Python gibt, was das ganze unangenehm macht hinsichtlich der Nebenläufigkeit (Stichwort: blocking von FHEM). Aber wer sich da heranwagen möchte, findet in discovery.py den Weg. Bis dahin ist die Angabe der IP des STP wohl auch nicht zu viel verlangt.

Nach der Analyse ist das von SpenZerX geschriebene und Waldmensch weiter entwickelte FHEM-Modul die einzige Vorgehensweise, einen STP abzufragen!

Da ich gerade 77_SMAEM.pm fertig zum SVN-Upload ins offizielle FHEM-Repository mache und Euer Modul für den STP "artverwandt ist" wollte ich fragen, ob ich das Modul nehmen, umbenennen (77_SMASTP.pm), dokumentieren und SVN-Upload-ready machen darf, um es dann in github und FHEM-SVN hoch zu laden!? Es würde damit unter GPL v3 gestellt werden und demnächst offizieller Teil von FHEM werden.
Ich würde mich dann als künftiger Maintainer zur Verfügung stellen (da muss es einen geben).
Dann noch die Frage: im Code ist ein Maik S. als Autor angegeben. Bist Du das, SpenZerX?

Ich muss fragen, weil das Modul keinen Copyright-Hinweis enthält und ich daher erst mal davon ausgehen muss, dass nur Maik S. darüber entscheiden darf, was damit passiert, weil er alleiniger Rechteinhaber ist und keinen Vermerkt darüber gemacht hat, wie das Modul verwendet werden darf. Und danach ggf. noch Waldmensch, der wohl nicht ganz unerheblich daran gearbeitet hat.

Natürlich kommen beim Upload in die Repositorys entsprechende Copyrightvermerke in das Modul, damit das geregelt ist.

Ich bite um kurze Stellungnahme, ob ihr damit einverstanden seid.

Gruß
Volker

Link zum SMA-Speedwire Repository:
https://github.com/kettenbach-it/FHEM-SMA-Speedwire

Waldmensch · 14 Mai 2016, 15:41:15

Meinen Segen hast Du auf jeden Fall. Den aktuellen Namen finde ich eh ein wenig sperrig, habe ihn aber aus Kompatibilitäts Gründen und Respekt vorm Autor nicht geändert. In jedem Fall sollten aber auch credits to SFBSpot mit rein dessen Quellcode der Ansatz ja mehr oder weniger entspringt. Ich werde das Modul auch nicht ewig maintainen können. Insofern fände ich es in (d)einem Repo besser aufgehoben, da dann patches von Anderen viel leichter einfließen können. Von meiner Seite werden nicht mehr viel Änderungen kommen, da es für meine Zwecke aktuell völlig ausreicht und auch aus dem Thread bisher keine Änderungswünsche kamen. Das wird sich sicher ändern, wenn es ein offizielles Release gibt. Mit dem Nonblocking habe ich mich noch nicht befasst, da das im Heimnetzwerk kaum ein Problem ist. Wenn es jemand einbaut - bitte, gerne, danke

Waldmensch · 14 Mai 2016, 15:53:41

Eventuell noch eine Anmerkung: wenn es zu einem Quasi Re-Launch durch Volker käme, sollte man über die Seriennummer im define nachdenken. Diese wird im Code weder gebraucht noch genutzt. Verschiedenen WR müssen eh über mehrere Modulinstanzen und die IP der WR abgefragt werden, es sei denn, es soll eine Art Autodetect rein. Dann könnte die SN des WR auf dem Ausgabeweg zur Identifizierung dienen. Selbst dann ist die Angabe der SN's durch den User nicht nötig, da diese in den Antwortpaketen der WR erstmaligen Erscheinung treten, aber nicht im Anfragepaket.

Gesendet von iPhone mit Tapatalk

Volker Kettenbach · 14 Mai 2016, 17:39:45

Zitat von: Waldmensch am 14 Mai 2016, 15:53:41
Eventuell noch eine Anmerkung: wenn es zu einem Quasi Re-Launch durch Volker käme, sollte man über die Seriennummer im define nachdenken. Diese wird im Code weder gebraucht noch genutzt.

Hab's aus dem Code rausgeworfen.
Bin eh dabei, den ganzen Code mal ein bisschen zu checken damit die Qualität stimmt.

Volker Kettenbach · 14 Mai 2016, 17:45:15

Ich hätte mal ein paar Fragen an alle User des Moduls:

- welche Firmwareversion ist auf Euren STP drauf?
- Wie oft bekommt ihr "Too little data received" im fhem-log? (Ah Moment, ich habe die Meldung geändert. Vorher stand da "Too less". Musste das korrigieren)
- Könnt ihr beobachten, dass ein gleichzeitig ausgeführtes ping auf die WR-IP zur deutlichen Laufzeitverlängerung (Faktor 10 oder mehr) beim Zugriff des FHEM-Moduls auf den WR führt? Insbesondere, wenn danach "Too little data received" erscheint?
- Bringt das Modul Euren WR aus dem Tritt? D.h. er antwortet nicht mehr auf ping und muss vom Netzwerk getrennt werden, so dass er nach dem Reconnect die IP per DHCP erneuert und dann wieder antwortet.

Waldmensch · 14 Mai 2016, 18:26:58

Alles kann ich dir von der Sonnenliege in Spanien nicht beantworten.
Ich kenne die Meldung eigentlich nur aus der Zeit, als noch mit der SN angefragt wurde. Danach hatte ich die Meldung nur noch bei Netzwerk Abbrüchen aufgrund neues Powerlan. Seit ich das durch ein Kabel ersetzt hab, läuft es wie ein Uhrwerk. Die Meldung kommt bei Antwort == null
Gleichzeitige Pings habe ich nie gemacht, ebenso wie andere Zugriffe. Allerdings kommuniziert der SHM ebenso über LAN mit dem WR ohne Probleme.
Als ich den Netzwerkadapter im WR nachgerüstet und angeschlossen hatte, wurde ca 10 Minuten ein Update aus dem Internet geladen. Somit denke ich, das der WR aktuell ist. Die exakte Version muss ich nachreichen.
Dein letzt geschildertes Problem kann ich nicht bestätigen. Habe dem WR in der Fritzbox eine quasi Feste IP zugewiesen, also er bekommt per dhcp immer dieselbe. Seit Einbau des Netzwerk Adapters wurde der WR nicht mehr von Netzwerk getrennt.

Ich habe in Code eigentlich soweit alles abgefangen, was an Fehlern auftreten kann um den restcode vor nullverweisen zu schützen. Eventuell musst Du da mal mehr Logmeldungen einrasten.

Volker Kettenbach · 14 Mai 2016, 18:35:08

Zitat von: Waldmensch am 14 Mai 2016, 18:26:58

Danach hatte ich die Meldung nur noch bei Netzwerk Abbrüchen aufgrund neues Powerlan. Seit ich das durch ein Kabel ersetzt hab, läuft es wie ein Uhrwerk.

Am Netzwerk liegt es definitiv nicht.
Aber das Modul kann den WR (Firmware 2.53) ziemlich aus dem Tritt bringen. Keine Ahnung wie und warum.
Lt. SMA sie die FW 2.54 stabiler. Die werde ich mal einspielen.

Bin gerade noch dabei, den Code ein bisschen auf zu räumen und eine Deutsche und Englische Doku zu schreiben.
Ich denke, ich habe das in den nächsten Tagen dann soweit für das einchecken ins SVN.
Wenn ich noch Fehler fixen kann, um so besser.

Waldmensch · 14 Mai 2016, 18:46:33

Jopp, je mehr Augen umso besser. Bin mit Perl nicht so Sattelfest.

DS_Starter · 14 Mai 2016, 19:56:32

Hallo Volker,

Zitatwelche Firmwareversion ist auf Euren STP drauf?

Es gibt verschiedene Komponenten in dem WR mit verschiedenen    Versionen:

Softwarepaket: 2.53.2.R
Firmware-Version der Logikkomponente:    0.10.0.R
Kommunikationsversion:    3.09.5.13
Firmware-Version des Hauptprozessors: 2.50.42.R
Firmware-Version der Kommunikationsbaugruppe: 2.51.23.R

Den gegenwärtigen Stand des STP Moduls hatte ich nicht weiter verfolgt. Ich würde gerne wieder mit hier einsteigen und testen / mitmachen wenn SMAEM rund ist und ich (b) wieder Zeit habe. Aber bin sehr daran interessiert.

Grüße
Heiko

Volker Kettenbach · 15 Mai 2016, 10:01:48

Zitat von: DS_Starter am 14 Mai 2016, 19:56:32
Softwarepaket: 2.53.2.R

Den gegenwärtigen Stand des STP Moduls hatte ich nicht weiter verfolgt. Ich würde gerne wieder mit hier einsteigen und testen / mitmachen wenn SMAEM rund ist und ich (b) wieder Zeit habe. Aber bin sehr daran interessiert.

Gemeint war das allgemeine Softwarepaket. Da habe ich auch die 2.53.2.R drauf. Ich denke, dass das für die Speedwire Kommunikation zuständig ist.
Ich werde in den nächsten Tagen mal die 2.54 aufspielen.

Das STP-Modul wird von mir jetzt gerade getestet und der Code ein bisschen bereinigt und dokumentiert.
Funktional gibt es voraussichtlich keine Änderungen gegenüber der letzten Version von Waldmensch.
Wenn alles klappt, mache ich heute oder morgen ein Release ins github. Dann könnt ihr mal testen.

Wenn dann alles passt, lade ich 77_SMAEM und 77_SMASTP dann ins offizielle FHEM-SVN hoch.

Volker Kettenbach · 15 Mai 2016, 10:11:40

Zitat von: Waldmensch am 14 Mai 2016, 18:26:58

Ich kenne die Meldung eigentlich nur aus der Zeit, als noch mit der SN angefragt wurde. Danach hatte ich die Meldung nur noch bei Netzwerk Abbrüchen aufgrund neues Powerlan. Seit ich das durch ein Kabel ersetzt hab, läuft es wie ein Uhrwerk. Die Meldung kommt bei Antwort == null

Hast Du auch einen SHM? Ich habe das Gefühl, dass der WR es nicht mag, wenn FHEM und SHM gleichzeitig zugreifen.

SpenZerX · 15 Mai 2016, 13:09:00

Zitat von: Volker Kettenbach am 14 Mai 2016, 12:59:17

Da ich gerade 77_SMAEM.pm fertig zum SVN-Upload ins offizielle FHEM-Repository mache und Euer Modul für den STP "artverwandt ist" wollte ich fragen, ob ich das Modul nehmen, umbenennen (77_SMASTP.pm), dokumentieren und SVN-Upload-ready machen darf, um es dann in github und FHEM-SVN hoch zu laden!? Es würde damit unter GPL v3 gestellt werden und demnächst offizieller Teil von FHEM werden.
Ich würde mich dann als künftiger Maintainer zur Verfügung stellen (da muss es einen geben).
Dann noch die Frage: im Code ist ein Maik S. als Autor angegeben. Bist Du das, SpenZerX?

Ich muss fragen, weil das Modul keinen Copyright-Hinweis enthält und ich daher erst mal davon ausgehen muss, dass nur Maik S. darüber entscheiden darf, was damit passiert, weil er alleiniger Rechteinhaber ist und keinen Vermerkt darüber gemacht hat, wie das Modul verwendet werden darf. Und danach ggf. noch Waldmensch, der wohl nicht ganz unerheblich daran gearbeitet hat.

Natürlich kommen beim Upload in die Repositorys entsprechende Copyrightvermerke in das Modul, damit das geregelt ist.

Ich bite um kurze Stellungnahme, ob ihr damit einverstanden seid.

Gruß
Volker

Link zum SMA-Speedwire Repository:
https://github.com/kettenbach-it/FHEM-SMA-Speedwire

Hallo Volker,

schön das du fragst. Ich glaube das Modul hat meinen standard Header und der sieht erstmal keine GPL Lizenz vor.

Du kannst aber in diesem speziellen Fall so wie beschrieben verfahren.

Also das Modul umbenennen und unter GPL der Masse zu Verfügung stellen. Es werden ja auch hohe Ansprüche an die Pflege der Module gestellt. Ich sehe da aktuell keinen Benefit für mich hier weitere Zeit zu Investieren, und dann möglicherweise von $MA verklagt zu werden. (War da nicht was?) Ich möchte meine Zeit lieber anderen Projekten widmen.

Meinen real Namen brauchst du auch nicht nennen. Vielleicht nennst du diesen Thread in dem Modul oder allenfalls "based on an Idea by SpenZerX and HDO".

Ich erkläre es hiermit zu GPL V2.

MFG

Waldmensch · 15 Mai 2016, 17:33:46

Zitat von: Volker Kettenbach am 15 Mai 2016, 10:11:40
Hast Du auch einen SHM? Ich habe das Gefühl, dass der WR es nicht mag, wenn FHEM und SHM gleichzeitig zugreifen.

Ja, ich habe einen SHM, von Anfang an. Erst war er über BT verbunden und mit Einbau der Netzwerkschnittstelle in den WR wurde BT deaktiviert und die Kommunikation erfolgt über das Heimnetzwerk. WR und SHM hängen an einem TP-Link 5 Port Switch und dieser geht per Kabel an meine Fritzbox. Der Raspi mit FHEM hängt über 2 Switches ebenfalls per Kabel an der Fritz. Sowohl SHM als auch FHEM arbeiten störungsfrei, zumindest bekomme ich keine Fehlermeldungen auf dem SunnyPortal und in FHEM kommen nun seit 3 Wochen lückenlos Daten. Allerdings werden durch das Modul auch leere bzw. ungültige Antworten ausgefiltert, damit keine Nullwerte in der LogDB /Readings landen. Das waren bei mir aber auch maximal 1-2 Logeinträge pro Woche (http://uploads.tapatalk-cdn.com/20160515/751755c3a427d4c8659e55ef02159ff3.jpg)