hmusb disconnect/init im sekundentakt

[the ratman]

hiho,

ich stelle grade fhem von raspi auf intel nuc (win10pro)/vm (debian) um.
hmlan rennt wie ein glöckerl, alles funzt.
vccu mach auch, was sie soll.
nun schließ ich meinen hmusb an, mach alles wie im wiki beschrieben, der stick wird auch erkannt und kann in fhem angelegt werden.

sobald ich ein (re)open mache, gehts im sekundentakt los und hört erst nach einem close des hmusb auf

Code Auswählen Erweitern

2018.02.24 17:53:40 1: logfile wurde von hand gelöscht
2018.02.24 17:56:19 1: HMLAN_Parse: hmusb new condition disconnected
2018.02.24 17:56:47 1: HMLAN_Parse: hmusb new condition init
2018.02.24 17:56:47 1: 127.0.0.1:1234 disconnected, waiting to reappear (hmusb)
2018.02.24 17:56:47 1: HMLAN_Parse: hmusb new condition disconnected
2018.02.24 17:56:47 1: HMLAN_Parse: hmusb new condition init
2018.02.24 17:56:47 1: 127.0.0.1:1234 reappeared (hmusb)
2018.02.24 17:56:48 1: 127.0.0.1:1234 disconnected, waiting to reappear (hmusb)
2018.02.24 17:56:48 1: HMLAN_Parse: hmusb new condition disconnected
2018.02.24 17:56:48 1: HMLAN_Parse: hmusb new condition init
2018.02.24 17:56:48 1: 127.0.0.1:1234 reappeared (hmusb)
2018.02.24 17:56:49 1: 127.0.0.1:1234 disconnected, waiting to reappear (hmusb)
...

ein list des hmusb

Code Auswählen Erweitern

Internals:
   CFGFN     
   DEF        127.0.0.1:1234
   DeviceName 127.0.0.1:1234
   NAME       hmusb
   NR         378
   NTFY_ORDER 50-hmusb
   STATE      disconnected
   TYPE       HMLAN
   XmitOpen   0
   assignedIDsCnt 0
   msgKeepAlive dlyMax:0 bufferMin:29
   msgLoadCurrent 0
   owner     
   owner_CCU  vccu
   READINGS:
     2018-02-24 17:56:57   Xmit-Events     init:314 disconnected:317
     2018-02-24 17:56:57   cond            disconnected
     2018-02-24 17:56:57   prot_disconnected last
     2018-02-24 17:56:57   prot_init       last
     2018-02-24 17:56:19   prot_keepAlive  last
     2018-02-24 17:56:57   state           disconnected
   helper:
     assIdCnt   0
     assIdRep   0
     setTime    46371
     cnd:
       253        317
       255        314
     ids:
     k:
       BufMin     29
       DlyMax     0
       Next       1519491442.01265
       Start      1519491417.01265
     loadLvl:
       bl         40
       a:
         99
         90
         40
         0
       h:
         0          low
         40         batchLevel
         90         high
         99         suspended
     log:
       all        0
       sys        0
       ids:
         ARRAY(0x55738fe265b0)
     q:
       HMcndN     253
       answerPend 0
       hmLanQlen  1
       keepAliveRec 0
       keepAliveRpt 0
       loadLastMax 0
       loadNo     0
       scnt       4
       ald:
         0
         0
         0
         0
         0
         0
         0
         0
         0
         0
         0
         0
       apIDs:
Attributes:
   group      hardware
   hmId       322433
   hmLanQlen  1_min
   icon       cul_usb
   loadLevel  0:low,40:batchLevel,90:high,99:suspended
   room       homematic

kann mir geholfen werden?

[MadMax-FHEM]

hmland "emuliert" ja für/mit dem hmusb einen lokalen HMLAN...

Was passiert, wenn du den hmland (wie im Wiki beschrieben) mit Debug direkt auf der Console startest (weiß aber nicht wie das jetzt unter Windows geht).

EDIT: ah VM mit Debian, dann wohl so wie im Wiki / dann evtl.: vielleicht wird usb nicht "sauber" durchgereicht?!

Da sollten ja evtl. Ausgaben kommen die helfen könnten.

Denn wenn hmland keinen "sauberen" HMLAN zur Verfügung stellen kann, dann kann der von fhem auch nicht stabil angesprochen werden.

Gruß, Joachim

[the ratman]

du meinst mit /opt/hmcfgusb/hmland -p 1234 -D ?
in der console kommt nix, ausser der blinkende cursor in ner neuen zeile.
wo müsste ich da suchen (log???) auf debian?

aja, wenns hilft: da ich ne linux-nulpe bin, hab ich auch x laufen. auf der grafischen oberfläche kann ich zumindest den dienst hmland nach belieben starten und stoppen, ohne dass blöde meldungen aufpoppen würden.

vielleicht wird usb nicht "sauber" durchgereicht?!

das befürchte ich auch - ich glaube, ich hab in nem log (hab leider die vm dazwischen auf 0 gesetzt) irgend ein io und/oder serial modul von perl in den warnings gesehen. mal gucken, was fhem beim nächsten restart dazu sagt. glaube, da war das warning, obwohl da noch kein usb in der vm aktiv war.
steh halt mit meinem achtelwissen ziemlich am schlauch gerade ...

NACHTRAG:
eben rennts das erste mal - ich hab tatsächlich nix anderes gemacht, als den dienst neu zu starten

Code Auswählen Erweitern

Xmit-Events init:315 disconnected:317 ok:1 2018-02-24 22:12:01
cond ok 2018-02-24 22:12:01

Code Auswählen Erweitern

2018.02.24 22:11:47 1: HMLAN_Parse: hmusb new condition init
2018.02.24 22:12:01 1: HMLAN_Parse: hmusb new condition ok
ist das allererste mal nach x versuchen. wenns so bleibt ...

woran das liegen könnte, würd mich aber extremst interessieren. der usb-stick ist quasi meine versicherung, wenn der hmlan mal versagt. wäre blöd, wenn der stick dann grad wieder nicht will.

[MadMax-FHEM]

Als Ersatz zum hmusb habe ich ein HMOD-PI-PCB (HM Aufsteckmodul für den PI).

Der lässt sich auch per USB-Adapter eben an USB betreiben oder aber per ESP sogar per WLAN...

Vielleicht eine (weitere) Alternative...

Gruß, Joachim

[the ratman]

wlan? bitte link!

glaube, ich hab mal hier irgendwo von nem eigenbau wlan-hm gelesen? das wäre schon interessanter und auch "universeller".
ein weiterer "sicherheitspunkt" ist nämlich: geht mein nuc ein, wird einfach das vm-backup auf nem baugleichen nuc angeworfen (ist halt ein bürorechner, aber zur not ... *g*). wenn ich da weder usb oder sonst was rumstecken muß, ist das in 1 min. und notfalls sogar von meiner holden erledigt.

trotzdem: ich würd gern vorbereitet sein ... wenn also jemand ne idee hat, wo dieses "stottern" her kommt und wie ichs in zukunft verhindern kann - ich wäre ewig dankbar.

[MadMax-FHEM]

Link such ich raus...

Kommt demnächst...

Gruß, Joachim

[the ratman]

sodale ...
neustart fhem ergibt ein weiterhin laufendes hmusb und tatsächlich hab ich mich richtig erinnert:

Code Auswählen Erweitern

18.02.25 08:49:22 1: usb create starting
2018.02.25 08:49:22 1: PERL WARNING: can't getattr: Input/output error at FHEM/DevIo.pm line 394.
2018.02.25 08:49:22 1: stacktrace:
2018.02.25 08:49:22 1:     main::__ANON__                      called by /usr/share/perl/5.24/Carp.pm (169)
2018.02.25 08:49:22 1:     Carp::carp                          called by /usr/lib/x86_64-linux-gnu/perl5/5.24/Device/SerialPort.pm (339)
2018.02.25 08:49:22 1:     Device::SerialPort::new             called by FHEM/DevIo.pm (394)
2018.02.25 08:49:22 1:     (eval)                              called by FHEM/DevIo.pm (392)
2018.02.25 08:49:22 1:     main::DevIo_OpenDev                 called by ./FHEM/98_autocreate.pm (587)
2018.02.25 08:49:22 1:     main::CommandUsb                    called by fhem.pl (1173)
2018.02.25 08:49:22 1:     main::AnalyzeCommand                called by fhem.pl (1026)
2018.02.25 08:49:22 1:     main::AnalyzeCommandChain           called by ./FHEM/91_notify.pm (104)
2018.02.25 08:49:22 1:     main::notify_Exec                   called by fhem.pl (3528)
2018.02.25 08:49:22 1:     main::CallFn                        called by fhem.pl (3448)
2018.02.25 08:49:22 1:     main::DoTrigger                     called by fhem.pl (601)das kommt insgesamt 5 mal beim restart, dann nicht mehr. hängt das eventuell zusammen?

[MadMax-FHEM]

Es ist dank dem zurechtschneiden wenig zu sehen...

Ist initialUsbCheck aktiv?

Andere USB Devices in Benutzung?

Links dauern noch, dazu brauch ich den PC...
...klimper aktuell nur am Handy...

Gruß, Joachim

[the ratman]

der check ist an ... sonst hätte fhem wohl nicht meinen hmusb gefunden, oder lieg ich da falsch?
und nö, die vm gibt derzeit ausser dem hmusb kein usb-gerät weiter an fhem.
des weiteren kann ich nur sagen, dass dieses warning am raspi mit den selben geräten und konfigurationen nicht kam. einziger unterschied ist vm und anstelle dem raspian ein vollwertiges debian.

und mit n link kannst dir zeit lassen - bin schon froh, dass es ne alternative gibt und ich irgendwann mal meinen armen nuc usb-sticks abstecken kann - der schaut aus wie n igel derzeit (nas, saugstation, mediaserver und backup1, alles eigene hdd's) *g*.
sag: kann dein wlan-spielzeug auch die neue ip-serie? das wäre genial, weil ich sowieso mal um das ip-zeugs erweitern will (siehe z.b. den "durchgangs-zähler").

[MadMax-FHEM]

InitialUSBCheck brauchst du eigentlich gar nicht

Maximal für direkt angesteckte USB-Geräte die auch als CUL etc. in fhem funktionieren sollen.
Soll/ist eine Erleichterung weil solche Geräte dann beim ersten Anstecken/Starten von fhem automatisch gesucht/gefunden werden und definiert werden.
Dabei versucht fhem/initialUsbCheck durch Abfrage herauszufinden um was es sich handelt.

Ergo: bei dir unnötig bzw. vielleicht/wahrscheinlich eher kontraproduktiv.

Ich würde es (und hab es bei mir auch) deaktivieren.

Entweder wie in der fhem.cfg kommentiert: auskommentieren...
...oder (empfohlen):

Code Auswählen Erweitern

attr initialUsbCheck disable 1


So dann hier mal ein paar Links bzgl. HM-MOD-PCB und USB/WLAN:

das "nackte" Funkmodul:
https://www.elv.de/homematic-funkmodul-fuer-raspberry-pi-bausatz.html

das Modul in fhem zur "Nutzung":
https://forum.fhem.de/index.php/topic,54511.0.html
https://wiki.fhem.de/wiki/HMUARTLGW

und ein paar Links bzgl. "anderer" Verwendung (USB/WLAN) (es gibt auch was dazu in dem [zugegebenermassen] länglichen Thread zum Modul):
https://forum.fhem.de/index.php/topic,62651.msg540843.html#msg540843
https://forum.fhem.de/index.php/topic,83602.msg758197.html#msg758197
https://forum.fhem.de/index.php/topic,81387.msg735350.html#msg735350
https://forum.fhem.de/index.php/topic,83602.msg758197.html#msg758197

(hab die jetzt aber nicht durch um zu sehen welche da jetzt relevant/brauchbar sind   )

Es gibt bestimmt weiteres im Forum und sogar "welche" die einen fertigen WLAN-HM-PCB "verkaufen"...

Wie gesagt einen USB-HMOD-PCB habe ich bereits im Schub liegen für den Fall, dass mein hmusb den Geist aufgibt...
...und am Testsystem habe ich direkt das Aufsteckmodul stecken (geht bei meinem Hauptsystem nicht, da dort bereits ein EnOcean-PI steckt).

Gruß, Joachim

[the ratman]

na dann mach ich mal nen disable beim check ... thx für die info!

jau, da gibste mir ja lesestoff.
thx für die abendbeschäftigung *g*

[the ratman]

leider gehts auch mit dem usb-stick weiter ...

Code Auswählen Erweitern

Xmit-Events disconnected:170 init:170 2018-02-26 09:38:39

und es is tatsächlich so, dass ich den dienst "hmland" einfach einmal stoppen und wieder starten muß.
sagts: da ich das per gui mache - wie lauten die befehle zum beenden und starten des dienstes? dann bau ich mir in fhem ne automatik, die das alle paar stunden mal erledigt.

[bsanders]

Servus,

vielleicht auch noch eine Möglichkeit, weil es mich so mal getroffen hatte. Ich hatte das Problem, dass mein altes Laptop nicht genug Leitung auf dem alten USB-Port "geschafft" hat. Anderen USB-Port versucht und gut war es.

Beste Grüße,
Bo

[MadMax-FHEM]

leider gehts auch mit dem usb-stick weiter ...

Code Auswählen Erweitern

Xmit-Events disconnected:170 init:170 2018-02-26 09:38:39

und es is tatsächlich so, dass ich den dienst "hmland" einfach einmal stoppen und wieder starten muß.
sagts: da ich das per gui mache - wie lauten die befehle zum beenden und starten des dienstes? dann bau ich mir in fhem ne automatik, die das alle paar stunden mal erledigt.

Von welchem USB-Stick sprichst du!?

HM-CFG-USB2 und dann per hmland!?

Oder einen HMOD-PCB mit USB-Adapter!?

Sind zwei total unterschiedliche Dinge!

Wie startest du hmlad?

Auf welchem System installiert!?

Weil mit systemd geht es etwas anders als mit initd...

Für Dienste starten/stoppen (ist hmland bei dir tatsächlich ein Service!?) gibt es ein Modul in fhem: serviced https://forum.fhem.de/index.php/topic,79952.msg719659.html#msg719659

Gruß, Joachim

[LuckyDay]

Alte Beiträge ausgraben von 2018