Antw:Läuft: Heizung mit eBus-Schnittstelle

[Dr. Boris Neubert]

Hallo Heiko,

Danke für den Test und die hilfreichen Logs. Ich vermute das Problem darin, dass die globale Schleife noch Daten meldet, und ECMD dann versucht, diese aus der geschlossenen Verbindung zu lesen.

Bitte ersetze doch noch die Subroutine durch folgende

Code Auswählen Erweitern

#####################################
# called from the global loop, when the select for hash->{FD} reports data
sub ECMD_Read($)
{
  my ($hash) = @_;
 
  return undef unless($hash->{state} eq "opened"); # avoid reading from closed device
 
  my $buf = ECMD_SimpleRead($hash);
  return unless(defined($buf));
  return if($buf eq "");
 
  ECMD_Log $hash, 5,  "Spontaneously received " . dq($buf);
  Dispatch($hash, $buf, undef);  # dispatch result to ECMDDevices
}


und teste dann noch einmal, was beim Abschalten des EBUS-Servers passiert.

Viele Grüße
Boris

[heikoh81]

Bei einem ersten Versuch blieb FHEM gefühlt 3 Sekunden hängen, danach lief es aber weiter
Problem: Starte ich ebusd auf dem Remote wieder, bleibt der State auf disconnected.
Auch set EBUS reopen ändert daran nicht sofort etwas.
Muss ich hier einfach länger warten?
Bei einem weiteren Versuch wurde es auch ohne set EBUS reopen recht schnell wieder erkannt.

Beim zweiten & dritten Versuch (ebusd manuell beendet) dann ca. 10-20 Sekunden bei 100% CPU-Load.
Solange es dabei bleibt, könnte ich damit leben.

[Dr. Boris Neubert]

Hallo,

FHEM belebt eine tote Verbindung (STATE "disconnected") erst wieder, wenn das Gerät etwas spontan sendet. Solange der STATE "disconnected" ist, kann nichts gesendet werden. Gibt es eine Möglichkeit, den EBUS-Server dazu zu bringen, von selbst Daten zu senden?

Ein set EBUS reopen sollte jedoch die Verbindung wiederherstellen, und zwar sofort. Kannst Du das bitte nochmal überprüfen und die relevante Passage aus dem Log (wie immer mit maximaler Geschwätzigkeit) hier posten, wenn es nicht klappen sollte?

Viele Grüße
Boris

[heikoh81]

Habe mal ein paar Versuche gemacht.
Wenn man geduldig genug ist (eine Tugend, die ich oft nicht habe ), dann wechselt der STATE wieder reproduzierbar auf opened - auch ohne set EBUS reopen.

Mit deinem Bugfix läuft FHEM jetzt stabil - die CPU-Load geht zwar für 10 - 20 Sekunden (nicht immer gleich lang) auf 100%, aber danach geht die CPU wieder in den Idle-Load (3-6%).
Das ist somit perfekt.

Baust du den Bugfix in ein Update ein, damit die 66_ECMD.pm zukünftig nicht manuell bearbeitet werden muss?

[Dr. Boris Neubert]

Hallo,

prima.

Du meinst die Änderung, wo nur

Code Auswählen Erweitern

  return undef unless($hash->{state} eq "opened"); # avoid reading from closed device

dazugekommen ist?

Das muss ich nur einchecken. OK?

Grüße
Boris

[heikoh81]

So genau habe ich den Code nicht angeschaut.
Der Code von 11:02 von dir jedenfalls funktioniert
Ich habe die komplette Routine in der 66_ECMD.pm durch deinen Code ersetzt und fhem neu gestartet.

Bei weiteren Versuchen habe ich übrigens bemerkt, dass die CPU-Load wesentlich kürzer auf 100% geht, wenn auf dem ebusd-Raspi eine kleinere Konfigurations-Datei eingesetzt wird - warum auch immer, eigentlich gibt es ja keine Verbindung zwischen den beiden Raspis außer über ECMD.

Code Auswählen Erweitern


#####################################
# called from the global loop, when the select for hash->{FD} reports data
sub ECMD_Read($)
{
  my ($hash) = @_;
 
  return undef unless($hash->{state} eq "opened"); # avoid reading from closed device
 
  my $buf = ECMD_SimpleRead($hash);
  return unless(defined($buf));
  return if($buf eq "");
 
  ECMD_Log $hash, 5,  "Spontaneously received " . dq($buf);
  Dispatch($hash, $buf, undef);  # dispatch result to ECMDDevices
}


[Dr. Boris Neubert]

soeben eingecheckt!

Viele Grüße
Boris

[heikoh81]

Ok, super, d.h. sichtbar sobald Rudolf es freigibt?
Update check liefert momentan:

Code Auswählen Erweitern


List of new / modified files since last update:
UPD ./CHANGED
UPD FHEM/00_SONOS.pm
UPD FHEM/10_CUL_HM.pm
UPD FHEM/21_SONOSPLAYER.pm
UPD FHEM/23_LUXTRONIK2.pm
UPD FHEM/59_PROPLANTA.pm
UPD FHEM/59_Twilight.pm
UPD FHEM/70_JSONMETER.pm
UPD FHEM/70_PIONEERAVR.pm
UPD FHEM/72_FRITZBOX.pm
UPD FHEM/98_HMinfo.pm
UPD FHEM/98_RandomTimer.pm
UPD FHEM/98_statistics.pm
UPD FHEM/HMConfig.pm
UPD docs/commandref.html
UPD docs/commandref_DE.html
UPD www/jscolor/ct_background.svg
UPD www/jscolor/hue_background.svg

New entries in the CHANGED file:
  - feature: 70_PIONEERAVR: readings for currentAlbum etc., more internals (network settings, moved some from readings to internals), new attributes volumeLimit & volumeLimitStraight



[Prof. Dr. Peter Henning]

Nein, durchaus im SVN schon jetzt sichtbar.

ich habe relativ gute Erfahrungen mit einer kleinen Routine gemacht, die sich selbst (via FHEM "at", max. 30 mal) in Abständen von 5 Sekunden aufruft, bis der EBUS wieder offen ist. Das ist bei mir notwendig, weil der Raspberry mit dem ebusd ebenfalls durch einen Watchdog überwacht wird, der ihn ggf. neu bootet.

Code Auswählen Erweitern


sub EBUSrecover($$)
{   
   my ($evt,$num) = @_;

   Log 1,"[EBUS] Recover triggered from $evt, attempt No. $num";
   
   if(Value("EBUS") ne "opened"){
     if( $num < 30){
       $num++;
       fhem("set EBUS reopen");
       fhem("delete EBUSrecoverdly")
          if($defs{"EBUSrecoverdly"});
       fhem("define EBUSrecoverdly at +00:00:05 {EBUSrecover('EBUSrecover',$num)}");
     }else{
       fhem("set Device.warn EBUS")
     }
   }
}


LG

pah

[heikoh81]

Nein, durchaus im SVN schon jetzt sichtbar.

Aber die Update-Routine zeigt die 66_ECMD.pm noch nicht an - das ist für mich als "Enduser" doch relevant, d.h. ich warte mit dem Update, bis es dort auftaucht?



Das Skript gefällt mir.
Ich packe es in die 99_myUtils.pm?

Und dann ein
define EBUSWatchdog notify EBUS { EBUSrecover() }
Welche Parameter müssen in die aufrufende Klammer?

Viele Grüße,
Heiko

[Prof. Dr. Peter Henning]

Code Auswählen Erweitern


(EBUS.*DISCONNECTED.*)|( <hier evtl. weitere Fehlerbedingungen) { EBUSrecover("notify EBUS.N",0)}


ja, steht in 99_myUtils.

@Dr. Boris Neubert: Wie wäre es denn, wenn man bei "set" Kommandos dem Frontend mitteilen könnte, welche Parameterwerte zulässig sind ? Dokumentiert ist nur das "normale" Textfeld, es wäre aber schön, wenn man mit

set <name>:<werteliste> cmd { Hier steht das Kommando }

z.B. eine Dropdown-Liste bekäme

LG

pah


LG

pah

[Luc115]

ECMD funktioniert nicht mehr nach update von 2-1-2015.

bug in 66_ECMD.pm Zeile 525: return undef unless($hash->{state} eq "opened");
"state" muss "STATE" sein.

Er gibt keine Fehler im FhemLog, aber ich bekomme keine readings mehr.
nach andern von "state" in "STATE" funktioniert es wieder.
ECMD ist definiert als serial device: define KAIFA ECMD serial /dev/ttyUSB0@115200

Luc

[heikoh81]

Kann dieser Fehler bestätigt werden?
Ich habe das Update noch gar nicht bestätigt, da ich immer noch den manuellen Hotfix im Post von Boris von 11:02 Uhr verwende.  Dieser ist aber identisch mit dem Update-File.
Ich habe keine Fehler im Log.

[hajo23]

hmm, ich habe heute das update durchgeführt und erhalte jetzt:
PERL WARNING: Use of uninitialized value in string eq at ./FHEM/66_ECMD.pm line 535.

Ich habe dann auch "state" in "STATE" geändert.

hajo

[Dr. Boris Neubert]

gefixt und eingecheckt - morgen früh per update verfügbar
bn