HM485 - Disconnected

[FNIK]

Hallo Gemeinde,
Seit dem letzten Update bekomme ich meine HM485 Komponenten nicht mehr zum laufen. Der HM485 ist im Status stets disconnected.
Im Log habe ich folgende Einträge:

2018.08.13 12:43:21 3: HM485_LAN: Start HM485d with command line: ./FHEM/lib/HM485/HM485d/HM485d.pl --hmwId 00000001 --serialNumber SGW0123456 --device /dev/ttyUSB0 --localPort 2000
2018.08.13 12:43:21 3: HM485_LAN: HM485d was started with PID:  17459
2018.08.13 12:43:21 3: HM485_LAN: Connect to HM485d delayed for 5 seconds
2018.08.13 12:43:21 3: Opening HM485_LAN device localhost:2000
Undefined subroutine &main::readingsSingleUpdate called at /opt/fhem/FHEM/lib/HM485/HM485d/../../../TcpServerUtils.pm line 37.

Kann es sein dass dies an der TCpServerUtils.pm vom 11.08.2018 liegt. Kopiere ich eine ältere Version ins FHEM Verzeichnis, startet FHEM gar nicht mehr.
VG Frank

[Treibhaus]

Hallo zusammen,

ich habe die selbe Herausforderung,  Schön das es endlich jemanden mit dem selben Anliegen zur Lösung gibt.

2018.08.13 15:36:15 3 : hm485: HM485d was started with PID: 1763
2018.08.13 15:36:15 3 : hm485: Connect to HM485d delayed for 5 seconds
2018.08.13 15:36:15 3 : Opening hm485 device localhost:2000
2018.08.13 15:36:17 3 : hm485: Start HM485d with command line: ./FHEM/lib/HM485/HM485d/HM485d.pl --hmwId 00000001 --serialNumber SGW0123456 --device /dev/ttyUSB0 --localPort 2000

Danach gibt es ein Timeout von 5sec und HM485d wird mit neuer PID gestartet , usw. , usw .

Den Fehler habe ich auch an der selben Stelle. Auskommentieren hat nicht geholfen, dann kommt ein Austieg der TCpServerUtils.pm bei Zeile183.
Gruß Jörg

[FNIK]

Hallo Treibhaus,

Das ist zumindest erst einmal für mich super und ich weiß das ich nicht durch meinen Code Wahnsinn irgendeinen Mist geschrieben habe.
Ich hätte das Thema wahrscheinlich bei HOMEMATIC Wired einstellen sollen, hoffe aber das uns hier auch ein Retter findet.
Was bei mir noch auffällig ist, es wird ständig eine neue PID erzeugt. Da stellt sich die Frage, ob eventl. mehrere Instanzen aufgerufen werden. Stoppen lässt sich das Interface dann auch nicht, da ja wieder eine neue aufgemacht wurde. Die Wired Geräte können nur mit einer Instanz. Vielleicht ist das noch ein Hinweiß an den weißen Ritter.

MfG Frank

[LuckyDay]

Code Auswählen Erweitern

Undefined subroutine &main::readingsSingleUpdate called at /opt/fhem/FHEM/lib/HM485/HM485d/../../../TcpServerUtils.pm line 37.
Undefined subroutine &main::readingsSingleUpdate called at /opt/fhem/FHEM/lib/HM485/HM485d/../../../TcpServerUtils.pm line 37.
Undefined subroutine &main::readingsSingleUpdate called at /opt/fhem/FHEM/lib/HM485/HM485d/../../../TcpServerUtils.pm line 37.
.
2018.08.13 14:44:40.900 1: hm485: Can't connect to localhost:2000: Verbindungsaufbau abgelehnt

ist mir heute mittag auch passiert, ich habe die TcpServerUtils.pm vom
TcpServerUtils.pm        16985 2018-07-15  genommen, damit geht HM485 WIEDER

[FNIK]

Hallo fhem-hm-knecht,
Kannst Du mir diese schicken oder bekommt man die auch im Netz?
VG Frank

[LuckyDay]

Findet man auch im SVN,

[FNIK]

Hey fhem-hm-knecht,
Du bist der weiße Ritter. Meine Installation läuft wieder. 
DANKE! DANKE! DANKE!
Ich hatte im SVN geschaut, jedoch leider nur die aktuellste Version 17132 laden können.
VG Frank

[FNIK]

Hallo fhem-hm-knecht,
Eine Frage habe ich noch. Wie bekommen jetzt die Entwickler mit? Ich habe schon vor dem nächsten Update Angst  .
VG Frank

[Ralf9]

siehe hier:
https://forum.fhem.de/index.php/topic,90221.0.html

Gruß Ralf

[Thorsten Pferdekaemper]

Hi,
das ist ja wirklich etwas hässlich. Wahrscheinlich ist es halt nicht "vorgesehen", dass irgendwas aus <fhem>/FHEM sozusagen ohne fhem.pl läuft. Die schnelle Lösung dürfte tatsächlich sein, eine Dummy-Variante von readingsSingleUpdate in HM485d.pl reinzupacken.
Hat das schon jemand ausprobiert? ...also in etwa:

Code Auswählen Erweitern


sub readingsSingleUpdate($$$$)
{
  # do nothing
}

Die "große" Lösung wäre wahrscheinlich, ein eigenes TcpServerUtils.pm mit HM485 auszuliefern. Das ist aber auch irgendwie hässlich.
Gruß,
   Thorsten

[Treibhaus]

 

Ich kann mich nur anhängen ! Bei mir läuft es auch direkt wieder !

Hier der Vergleich der beiden Dateien:

2c2
< # $Id: TcpServerUtils.pm 16985 2018-07-15 14:08:15Z rudolfkoenig $
---
> # $Id: TcpServerUtils.pm 17124 2018-08-11 06:54:58Z rudolfkoenig $
37c37
<   $hash->{STATE} = "Initialized";
---
>   readingsSingleUpdate($hash, "state", "Initialized", 0);
148c148
<   $nhash{STATE} = "Connected";
---
>   readingsSingleUpdate(\%nhash, "state", "Connected", 0);

Besten Dank.
Updates lasse ich dann bis zur endlichen Lösung !

Gruß Jörg

[betateilchen]

Hat mal jemand versucht, in den Kopf von TcpServerUtils.pm einfach eine Forward-Deklaration von readingsSingleUpdate zu schreiben? [/s]

Habe gerade keine Möglichkeit, das selbst zu testen.



Edit: oder direkt in die ServerTools.pm?

Code Auswählen Erweitern


use vars qw($winService);  # the Windows Service object
use vars qw($init_done);

sub readingsSingleUpdate($$$$);


[Thorsten Pferdekaemper]

Edit: oder direkt in die ServerTools.pm?

Was soll das bringen? Spätestens wenn das System versucht, das Ding aufzurufen kracht's dann doch wieder. Oder?
...ich werde das interessehalber auch mal ausprobieren.
Gruß,
   Thorsten

[Thorsten Pferdekaemper]

Hi,
also wie vermutet hat eine Deklaration nicht gereicht, da musste schon eine Definition her. (Wie ja die Fehlermeldung schon nahelegt.)
Das Problem müsste jetzt mit einem "update" bzw "update all hm485" erledigt sein.
Gruß,
   Thorsten

[betateilchen]

Was soll das bringen? Spätestens wenn das System versucht, das Ding aufzurufen kracht's dann doch wieder. Oder?

Mit der Gesamtarchitektur des HM485d habe ich mich nicht beschäftigt. Es hätte durchaus sein können, dass die Funktion einfach zu dem Zeitpunkt, zu dem das Hilfsmodul geladen wird, noch nicht zur Verfügung steht, aber später dazukommt. In solchen Fällen kann ein Deklaration manchmal schon helfen. Deshalb hatte ich ja geschrieben, dass ich es nicht selbst testen kann.