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 auf2018.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 hmusbInternals:
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?
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
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.
Zitatvielleicht 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
Xmit-Events init:315 disconnected:317 ok:1 2018-02-24 22:12:01
cond ok 2018-02-24 22:12:012018.02.24 22:11:47 1: HMLAN_Parse: hmusb new condition init
2018.02.24 22:12:01 1: HMLAN_Parse: hmusb new condition okist 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.
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
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.
Link such ich raus...
Kommt demnächst...
Gruß, Joachim
sodale ...
neustart fhem ergibt ein weiterhin laufendes hmusb und tatsächlich hab ich mich richtig erinnert: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?
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
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").
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):
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
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*
leider gehts auch mit dem usb-stick weiter ... 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.
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
Zitat von: the ratman am 26 Februar 2018, 09:39:34
leider gehts auch mit dem usb-stick weiter ... 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
Alte Beiträge ausgraben von 2018 ;D
Zitat von: fhem-hm-knecht am 05 Oktober 2020, 22:51:00
Alte Beiträge ausgraben von 2018 ;D
Da hast du recht ;)
Aber so ist es halt wenn ein alter Thread aufpopt und man denkt man ist noch was schuldig... ;)
Gruß, Joachim