Neues Modul: TEK603

[gnampf]

Ich hab mal am Modul etwas rumgepatcht, damit die Verbindung auch via ser2net funktioniert. Ich hoffe direkt angeklemmt funktionierts weiterhin...

Für ser2net einfach folgenden Eintrag erstellen in der Config:

Code Auswählen Erweitern

23001:raw:0:/dev/serial/by-id/usb-Silicon_Labs_CP2102_USB_to_UART_Bridge_Controller_0001-if00-port0:115200 8DATABITS NONE 1STOPBIT

und dann bei fhem

Code Auswählen Erweitern

define Zisterne TEK603 hostname:23001

Port darf natürlich auch was anderes als 23001 sein.

[eisler]

ser2net patch mit eingebaut: https://svn.fhem.de/trac/changeset/19936/trunk/fhem

Grüße
Stephan

[fiedel]

Hallo Stephan,

weißt du wie man eine Sub wie die "TEK603_reconnect($)" von der FHEM- Eingabezeile aus aufrufen kann?
Was müsste übergeben werden, damit das Reconnect ausgeführt wird? Bzw. wäre es möglich ein
"set <name> reopen" einzubauen?
Bei mir hängt sich die Schnittstelle öfter mal auf und ich bekomme keine Daten mehr, obwohl der Empfänger
aktuelle Daten hat. Wenn ich das Modul dann redefiniere kommen die Daten wieder. Somit sollte die Schnittstelle
unter Linux nicht gehangen haben, sondern das Problem innerhalb FHEM liegen.
Ich würde also gern automatisiert ein "Reconnect" bzw. "Reopen" ausführen.

Gruß
Frank

Edit: Konnte es jetzt selbst lösen: Man definiert ein at, welches ein Mal am Tag einfach die DEF des Moduls wiederholt.
        Damit wird das Modul redifined und verbindet sich erneut mit der Schnittstelle.

         Hier gab es wieder einen Hänger (zu erkennen an "addLog") und um 1:00Uhr hat das at den Datenfluss wiederbelebt:

Code Auswählen Erweitern

2020-06-20_07:19:29 Sens_L_Zisterne content: 2.1
2020-06-20_07:50:47 Sens_L_Zisterne content: 2.1
2020-06-20_08:22:05 Sens_L_Zisterne content: 2.1
2020-06-20_09:21:15 Sens_L_Zisterne content: 2.1      << addLog
2020-06-20_12:21:16 Sens_L_Zisterne content: 2.1      << addLog
2020-06-20_15:21:15 Sens_L_Zisterne content: 2.1      << addLog
2020-06-20_18:21:16 Sens_L_Zisterne content: 2.1      << addLog
2020-06-20_21:21:15 Sens_L_Zisterne content: 2.1      << addLog
2020-06-20_23:59:00 Sens_L_Zisterne content: 2.1      << addLog
2020-06-21_00:01:00 Sens_L_Zisterne content: 2.1      << addLog
2020-06-21_00:21:16 Sens_L_Zisterne content: 2.1      << addLog
2020-06-21_01:00:00 Sens_L_Zisterne content: 2.1
2020-06-21_01:27:16 Sens_L_Zisterne content: 2.2
2020-06-21_01:58:32 Sens_L_Zisterne content: 2.2
2020-06-21_02:29:49 Sens_L_Zisterne content: 2.2
2020-06-21_03:01:05 Sens_L_Zisterne content: 2.2

[eisler]

Hallo Frank,

ein patch könnte ich mit einbauen, für mehr fehlt gerade die Zeit.

Grüße
Stephan

[choetzu]

Guten Tag,

ich habe das Modul erfolgreich am Laufen... Jedoch wenn ich den USB Stick nicht eingesteckt habe, startet FHEM gar nicht erst und folgende Nachricht wird geloggt.
Ich kann das device auch nicht disablen... Es bleibt nur die Deinstallation des Moduls.. Was ich nicht sehr sexy finde.. Gibts eine andere Möglichkeit?

Software error:


Can't call method "status" on an undefined value at ./FHEM/44_TEK603.pm line 147.



For help, please send mail to this site's webmaster, giving this error message
and the time and date of the error.


[Sat Feb 29 09:29:05 2020] fhem.pl: Can't call method "status" on an undefined value at ./FHEM/44_TEK603.pm line 147.

[eisler]

ich schau mal was ich machen kann.

Grüße
Stephan

[eisler]

Hallo choetzu,

Attribute: disabled hinzugefügt.

Grüße
Stephan

[Christoph Morrison]

Hallo Stephan,

ich würde noch mal gerne auf das Thema mit dem FHEM-Restart zurück kommen, dass choetzu auch schon bemerkt hat.
Wenn ich mein FHEM auf der Integration-Test-Maschine testen möchte, habe ich dort nur entweder gar kein USB-Device (oder nur einen Link auf /dev/zero o.ä.) und es würde schon reichen, wenn der Aufruf von $po->status() z.B. in einem eval-Block aufgefangen würde oder nur auf $po zu prüfen. Ich hatte das mal bei mir gemacht, aber das Device versucht hartnäckig, den Status zu lesen. Wäre schön, wenn das Device irgendwann merkt dass es partout keine Daten bekommt und dann auch damit aufhört.

Davon abgesehen macht es einen Integrationstest natürlich schwierig, wenn man dann je nach Umgebung Attribute setzen muss (und FHEM keine Conditionals darin unterstützt).
Ich hatte die Hoffnung dass das dummy-Attribut irgendwas tut, aber .. nein, tut es nicht (ist auch nicht dokumentiert, bin nur zufällig drüber gestolpert).

So sieht meine TEK603_ready aus (ohne den nutzlosen Prototypen):

Code Auswählen Erweitern


sub TEK603_ready() {
        my ($hash) = @_;
        my $name = $hash->{NAME};
        return if (IsDisabled($name));
        return DevIo_OpenDev($hash, 1, 'TEK603_doInit') if($hash->{STATE} eq 'disconnected');

        # This is relevant for windows/USB only
        my $po = $hash->{USBDev};

        my ($BlockingFlags, $InBytes, $OutBytes, $ErrorFlags);

        if ($po) {
                ($BlockingFlags, $InBytes, $OutBytes, $ErrorFlags) = $po->status;
                return ($InBytes > 0);
        }

        Log3($name, 3, $ErrorFlags);
        Log3($name, 3, q{Can't call $po->status});
        return;
}



In $ErrorFlags ist nie etwas enthalten, btw.

Code Auswählen Erweitern


2020.06.04 19:51:00.231 3: Can't call $po->status
2020.06.04 19:51:00.261 3: Can't call $po->status
2020.06.04 19:51:00.262 3: Can't call $po->status
2020.06.04 19:51:00.268 3: Can't call $po->status
2020.06.04 19:51:00.682 3: Can't call $po->status
2020.06.04 19:51:00.754 3: Can't call $po->status
2020.06.04 19:51:00.755 3: Can't call $po->status
2020.06.04 19:51:01.109 3: Can't call $po->status
2020.06.04 19:51:01.174 3: Can't call $po->status
2020.06.04 19:51:01.175 3: Can't call $po->status
2020.06.04 19:51:01.199 3: Can't call $po->status
2020.06.04 19:51:01.200 3: Can't call $po->status
2020.06.04 19:51:01.227 3: Can't call $po->status
2020.06.04 19:51:01.234 3: Can't call $po->status
2020.06.04 19:51:01.397 3: Can't call $po->status
2020.06.04 19:51:01.398 3: Can't call $po->status
2020.06.04 19:51:01.594 3: Can't call $po->status
2020.06.04 19:51:01.714 3: Can't call $po->status
2020.06.04 19:51:01.715 3: Can't call $po->status
2020.06.04 19:51:02.240 3: Can't call $po->status


Ich war eben mal mutig und hab den Empfänger meiner Proteus-Rakete gezogen - gleiches Bild im Live-Betrieb, wenn das USB-Device plötzlich weg ist. Hat mein FHEM auch ganz gut ausgelastet, ein Restart funktioniert dann auch nicht mehr

[eisler]

Hallo Christoph,

da ich gerade keinen zugriff auf ein Testsetup habe kann ich das leider nicht nachstellen.
Sollte bei deinen Tests ein Patch für das Modul herauskommen kann ich den gerne übernehmen.

Grüße
Stephan

[Christoph Morrison]

Hi,

schau mal hier: https://bitbucket.org/christoph-morrison/fhem-patches/src/master/FHEM/44_TEK603.pm/she2Aedai3.patch

[eisler]

done. https://svn.fhem.de/trac/changeset/22136/trunk/fhem

Grüße
Stephan

[Phili]

Hi,

Gibt es die Möglichkeit die Frequenz von alle 30min auf alle 15min oder alle 10min zu ändern?
Grund dafür ist, dass wenn ich mein Garten bewässere ändert sich der Füllstand definitiv mehr als 3cm/h aber er schaltet trotzdem nicht in den Echtzeitmodus. Alle 30min ist zu träge um die Frischwasser Zufuhr zu steuern damit die Zisterne nicht leer läuft.

Grüße
Philipp

[eisler]

Hallo Philipp,

meines Wissens ist der Wert nicht änderbar. Der ist fest in der Firmware des Gerätes. Deshalb gibt es auch Füllstandsanzeige für Heizöltanks mit Messdaten in 60min Intervallen und Füllstandsanzeige für Zisterne, Wassertanks mit 30min Intervallen.

Grüße
Stephan

[Christoph Morrison]

Gibt es die Möglichkeit die Frequenz von alle 30min auf alle 15min oder alle 10min zu ändern?
Grund dafür ist, dass wenn ich mein Garten bewässere ändert sich der Füllstand definitiv mehr als 3cm/h aber er schaltet trotzdem nicht in den Echtzeitmodus. Alle 30min ist zu träge um die Frischwasser Zufuhr zu steuern damit die Zisterne nicht leer läuft.

IMHO sind die Geräte für solch eine Überwachung nicht geeignet. Der Meldezyklus ist grundsätzlich zu lang um irgendwas punktgenau damit zu steuern. Für sowas brauchst du einen Schwimmerschalter als Sicherheitsmechanismus.

[Phili]

Danke Stephan und Christoph!