Probleme mit HMLAN/FHEM/Fenstersensoren?

Begonnen von selfarian, 09 April 2015, 16:06:15

Vorheriges Thema - Nächstes Thema
Drucken
Nach unten Seiten 1 2 3 Alle
Benutzer-Aktionen

selfarian

#15
14 April 2015, 14:11:28
Ich werde mal versuchen, beide Geräte direkt an die Fritzbox, bzw. den selben switch zu hängen, vielleicht löst sich dann das Disconnect Problem.
Wie komme ich an die rssi-werte?
Ich hatte bei dem "defekten" hm-sec-sc2 auch versucht gehabt, ihn zu pairen, bzw. getConfig "auszuführen" als ich direkt neben dem HMLAN-Adapter stand um auszuschließen, das es die Reichweite ist.
RasPi mit HMLAN, 5x HM-SEC-SC, HM LED16 als Alarmanlagendisplay, HM-TC-IT-WM-W-EU, 4x HM-CC-RT-DN, 1x HM PBU, 1x HM PBI-4

frank

#16
14 April 2015, 14:59:32
ZitatWie komme ich an die rssi-werte?
zb get rssi über hminfo.

Zitatals ich direkt neben dem HMLAN-Adapter stand um auszuschließen, das es die Reichweite ist.
zu dicht ist auch schlecht. zum testen am besten 2-3 meter abstand.
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

selfarian

#17
14 April 2015, 15:09:53 Letzte Bearbeitung: 14 April 2015, 15:27:32 von selfarian
Hier wären die rssi-werte schon mal:

Code Auswählen
    Device          receive         from             last   avg      min<max    count
    CUL_HM_HM_CC_RT_DN_236BCB HMLAN1          CUL_HM_HM_CC_RT_DN_236BCB  -82.0  -85.6 -102.0< -78.0   458
    CUL_HM_HM_CC_RT_DN_31354C CUL_HM_HM_CC_RT_DN_31354C HMLAN1           -78.0  -77.0  -78.0< -76.0     2
    CUL_HM_HM_CC_RT_DN_31354C HMLAN1          CUL_HM_HM_CC_RT_DN_31354C  -78.0  -78.6 -101.0< -74.0   458
    CUL_HM_HM_CC_RT_DN_3136CC CUL_HM_HM_CC_RT_DN_3136CC HMLAN1           -69.0  -69.0  -69.0< -69.0     2
    CUL_HM_HM_CC_RT_DN_3136CC HMLAN1          CUL_HM_HM_CC_RT_DN_3136CC  -68.0  -67.7  -71.0< -64.0   472
    CUL_HM_HM_CC_RT_DN_313CC3 HMLAN1          CUL_HM_HM_CC_RT_DN_313CC3  -58.0  -57.6  -63.0< -57.0   450
    CUL_HM_HM_TC_IT_WM_W_EU_2D3145 CUL_HM_HM_TC_IT_WM_W_EU_2D3145 HMLAN1           -42.0  -42.0  -42.0< -42.0     4
    CUL_HM_HM_TC_IT_WM_W_EU_2D3145 HMLAN1          CUL_HM_HM_TC_IT_WM_W_EU_2D3145  -51.0  -51.0  -51.0< -51.0   930
    HM_1A959E       HMLAN1          HM_1A959E        -59.0  -62.8  -72.0< -59.0     4
    LED16           HMLAN1          LED16            -73.0  -76.0  -88.0< -72.0   288
    LED16           LED16           HMLAN1           -74.0  -76.2  -80.0< -72.0   255
    fl_fenster      HMLAN1          fl_fenster       -84.0  -88.8 -101.0< -80.0    15
    fl_licht        HMLAN1          fl_licht         -80.0  -80.2  -82.0< -79.0    16
    fl_licht        fl_licht        HMLAN1           -81.0  -81.5  -83.0< -81.0    11
    fl_taster       HMLAN1          fl_taster        -80.0  -80.0  -80.0< -80.0     1
    spz_fenster     HMLAN1          spz_fenster      -95.0  -95.0  -95.0< -95.0     1
Edit: Sorry, Formatierung war verloren gegangen...
RasPi mit HMLAN, 5x HM-SEC-SC, HM LED16 als Alarmanlagendisplay, HM-TC-IT-WM-W-EU, 4x HM-CC-RT-DN, 1x HM PBU, 1x HM PBI-4

frank

#18
14 April 2015, 15:52:14
die 2 fenster devices sehen nicht gut aus. ein rt ebenfalls.

grob gesagt, würde ich behaupten, alles kleiner -80 könnte problematisch werden. gerade wenn der avg deutlich tiefer liegt. wenn dein problem-fenster dabei ist, solltest du die werte verbessern.

ich habe bei meinem hmlan ein kleines loch ins gehäuse gebohrt und dort den antennendraht gerade nach aussen geführt. zusätzlich noch etwas zentraler aus dem regal an die wand gehängt. das brachte fast bei allen devices 10-20 punkte bessere rssi. bei meinen fensterkontakten habe ich das auch gemacht.
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

selfarian

#19
14 April 2015, 20:57:00
Ok. Gut zu wissen. Zwischeninfo: das Umstecken vom Raspberry hat leider nichts geholfen. Ich habe immernoch die Disconnects obwohl HMLAN und Raspberry direkt an der Fritzbox hängen.

Zum Thema Empfang habe ich mich jetzt mal mit dem Dimmer versucht (HM_1A959E) der sollte ja vom rssi Wert er ok sein. Allerdings kriege ich hier auch (wieder) ein response timeout bei einem getConfig.
RasPi mit HMLAN, 5x HM-SEC-SC, HM LED16 als Alarmanlagendisplay, HM-TC-IT-WM-W-EU, 4x HM-CC-RT-DN, 1x HM PBU, 1x HM PBI-4

selfarian

#20
14 April 2015, 21:23:48
So, mit apptime habe ich jetzt mal ein performancefresser rausgenommen (TV-Programm).
Im Moment sieht mein Log nicht sehr berauschend aus, was den performancemonitor angeht:
Code Auswählen
2015.04.14 21:15:12 0: Server shutdown
2015.04.14 21:15:36 2: Perfmon: ready to watch out for delays greater than one second
2015.04.14 21:15:42 3: telnetPort: port 7072 opened
2015.04.14 21:15:43 3: WEB: port 8083 opened
2015.04.14 21:15:43 3: WEBphone: port 8084 opened
2015.04.14 21:15:43 3: WEBtablet: port 8085 opened
2015.04.14 21:15:45 1: HMLAN_Parse: HMLAN1 new condition disconnected
2015.04.14 21:15:45 3: Opening HMLAN1 device 192.168.150.11:1000
2015.04.14 21:15:45 3: HMLAN1 device opened
2015.04.14 21:15:45 1: HMLAN_Parse: HMLAN1 new condition init
2015.04.14 21:15:50 3: Allguth: Defined with URL http://www.clever-tanken.de/tankstelle_details/98 and interval 600
2015.04.14 21:15:50 3: Shell: Defined with URL http://www.clever-tanken.de/tankstelle_details/6564 and interval 600
2015.04.14 21:15:50 3: HundH: Defined with URL http://www.clever-tanken.de/tankstelle_details/28645 and interval 600
2015.04.14 21:15:51 3: Opening FritzBoxCallMonitor device 192.168.150.1:1012
2015.04.14 21:15:51 3: FritzBoxCallMonitor device opened
2015.04.14 21:15:51 3: FB_CALLMONITOR (FritzBoxCallMonitor) - loading cache file /opt/fhem/callmoncache.txt
2015.04.14 21:15:51 2: FB_CALLMONITOR (FritzBoxCallMonitor) - read 6 contacts from Cache
2015.04.14 21:15:57 2: eventTypes: loaded 2012 events from log/eventTypes.txt
2015.04.14 21:15:58 3: Connecting to database mysql:database=fhem;host=localhost;port=3306 with user fhemuser
2015.04.14 21:15:58 3: Connection to db mysql:database=fhem;host=localhost;port=3306 established for pid 3708
2015.04.14 21:15:58 3: Connection to db mysql:database=fhem;host=localhost;port=3306 established
2015.04.14 21:16:01 3: Registering HTTPSRV tablet_ui for URL /tablet...
2015.04.14 21:16:04 3: DBPlan_Define (SBahnMuenchen) - defined with interval 60 (sec)
2015.04.14 21:16:04 3: DBPlan_Define (SBahnNeufahrn) - defined with interval 60 (sec)
2015.04.14 21:16:07 3: NTFY return:  FritzBoxCallMonitor:Could not read FritzBox phonebook file - Error on reading /opt/fhem/fb_phonebook.xml from database!
2015.04.14 21:16:07 0: Server started with 274 defined entities (version $Id: fhem.pl 8430 2015-04-13 17:03:56Z rudolfkoenig $, os linux, user fhem, pid 3708)
2015.04.14 21:16:07 1: Perfmon: possible freeze starting at 21:15:37, delay is 30.798
2015.04.14 21:16:08 3: telnetForBlockingFn: port 53455 opened
2015.04.14 21:16:16 1: HMLAN_Parse: HMLAN1 new condition ok
2015.04.14 21:16:22 1: Perfmon: possible freeze starting at 21:16:08, delay is 14.936
2015.04.14 21:16:22 3: Device CUL_HM_HM_CC_RT_DN_236BCB added to ActionDetector with 000:10 time
2015.04.14 21:16:25 3: Device CUL_HM_HM_CC_RT_DN_31354C added to ActionDetector with 000:10 time
2015.04.14 21:16:25 3: Device CUL_HM_HM_CC_RT_DN_3136CC added to ActionDetector with 000:10 time
2015.04.14 21:16:26 3: Device CUL_HM_HM_CC_RT_DN_313CC3 added to ActionDetector with 000:10 time
2015.04.14 21:16:27 3: Device CUL_HM_HM_TC_IT_WM_W_EU_2D3145 added to ActionDetector with 000:10 time
2015.04.14 21:16:28 3: Device az_fenster added to ActionDetector with 028:00 time
2015.04.14 21:16:29 3: CUL_HM set LED16_11_Alarm_Arbeitszimmer led green
2015.04.14 21:16:29 3: CUL_HM set LED16_03_Alarm_Status_EG led green
2015.04.14 21:16:30 3: Device fl_fenster added to ActionDetector with 028:00 time
2015.04.14 21:16:31 3: CUL_HM set LED16_07_Alarm_Status_Haustuere led green
2015.04.14 21:16:32 3: CUL_HM set LED16_03_Alarm_Status_EG led green
2015.04.14 21:16:33 3: Device fl_rauchmelder added to ActionDetector with 099:00 time
2015.04.14 21:16:34 3: Device k_fenster added to ActionDetector with 028:00 time
2015.04.14 21:16:34 3: CUL_HM set LED16_14_Alarm_Kueche led green
2015.04.14 21:16:35 3: CUL_HM set LED16_04_Alarm_Status_ZG led green
2015.04.14 21:16:43 3: Device spz_fenster added to ActionDetector with 028:00 time
2015.04.14 21:16:44 3: CUL_HM set LED16_03_Alarm_Status_EG led green
2015.04.14 21:16:46 3: Device wz_fenster added to ActionDetector with 028:00 time
2015.04.14 21:16:47 3: CUL_HM set LED16_13_Alarm_Wohnzimmer led green
2015.04.14 21:16:48 3: CUL_HM set LED16_04_Alarm_Status_ZG led green
2015.04.14 21:16:50 1: 192.168.150.11:1000 disconnected, waiting to reappear (HMLAN1)
2015.04.14 21:16:50 1: HMLAN_Parse: HMLAN1 new condition disconnected
2015.04.14 21:16:52 1: 192.168.150.11:1000 reappeared (HMLAN1)
2015.04.14 21:16:52 1: HMLAN_Parse: HMLAN1 new condition init
2015.04.14 21:16:53 1: Perfmon: possible freeze starting at 21:16:23, delay is 30.633
2015.04.14 21:16:54 3: CUL_HM set wz_licht statusRequest
2015.04.14 21:17:16 1: HMLAN_Parse: HMLAN1 new condition ok
2015.04.14 21:17:36 1: Perfmon: possible freeze starting at 21:16:54, delay is 42.669
2015.04.14 21:17:36 3: CUL_HM set HM_1A959E_Sw1_V_01 statusRequest
2015.04.14 21:17:40 1: Perfmon: possible freeze starting at 21:17:37, delay is 3.895
2015.04.14 21:17:40 3: CUL_HM set HM_1A959E_Sw1_V_02 statusRequest
2015.04.14 21:17:41 3: CUL_HM set fl_licht statusRequest
2015.04.14 21:17:43 1: Perfmon: possible freeze starting at 21:17:42, delay is 1.298
2015.04.14 21:17:43 3: CUL_HM set fl_rauchmelder statusRequest
2015.04.14 21:18:14 1: Perfmon: possible freeze starting at 21:17:45, delay is 29.139
2015.04.14 21:18:15 1: 192.168.150.11:1000 disconnected, waiting to reappear (HMLAN1)
2015.04.14 21:18:15 1: HMLAN_Parse: HMLAN1 new condition disconnected
2015.04.14 21:18:16 1: 192.168.150.11:1000 reappeared (HMLAN1)
2015.04.14 21:18:16 1: HMLAN_Parse: HMLAN1 new condition init
2015.04.14 21:18:17 1: Perfmon: possible freeze starting at 21:18:15, delay is 2.206
2015.04.14 21:18:23 1: HMLAN_Parse: HMLAN1 new condition ok
2015.04.14 21:18:24 1: Perfmon: possible freeze starting at 21:18:18, delay is 6.453
2015.04.14 21:18:25 3: CUL_HM set LED16_08_Licht_gesamt led off
2015.04.14 21:18:25 3: CUL_HM set LED16_08_Licht_gesamt led off
2015.04.14 21:18:26 3: CUL_HM set LED16_08_Licht_gesamt led off
2015.04.14 21:18:26 3: CUL_HM set LED16_08_Licht_gesamt led off
2015.04.14 21:18:26 3: CUL_HM set LED16_08_Licht_gesamt led off
2015.04.14 21:18:29 1: PERL WARNING: Subroutine HandleTimeout redefined at ./FHEM/98_apptime.pm line 24.
2015.04.14 21:18:29 1: PERL WARNING: Subroutine CallFn redefined at ./FHEM/98_apptime.pm line 58.
2015.04.14 21:18:29 1: Perfmon: possible freeze starting at 21:18:25, delay is 4.544
2015.04.14 21:18:31 3: CUL_HM set HM_1A959E getConfig
2015.04.14 21:18:33 1: Perfmon: possible freeze starting at 21:18:30, delay is 3.304
2015.04.14 21:18:38 1: Perfmon: possible freeze starting at 21:18:34, delay is 4.773
2015.04.14 21:19:22 1: Perfmon: possible freeze starting at 21:19:17, delay is 5.211
2015.04.14 21:19:34 1: Perfmon: possible freeze starting at 21:19:31, delay is 3.227
2015.04.14 21:19:47 1: Perfmon: possible freeze starting at 21:19:46, delay is 1.928
2015.04.14 21:20:07 1: Perfmon: possible freeze starting at 21:20:06, delay is 1.288

Apptime gibt mir im Moment folgendes aus:
Code Auswählen
  name             function    max  count    total  average maxDly
                              HMLAN1           HMLAN_Read   8547     29    49303  1700.10      0 HASH(HMLAN1)
                               logdb            DbLog_Log   6636     54    52877   979.20      0 HASH(logdb); HASH(wz_heizung)
        FHEMWEB:192.168.150.20:51032              FW_Read   5520     17     5652   332.47      0 HASH(FHEMWEB:192.168.150.20:51032)
                   tmr-CUL_HM_procQs        CUL_HM_procQs   2058      1     2058  2058.00   1098 CUL_HM_procQs
          tmr-ROOMMATE_DurationTimer      HASH(0x2d08c28)   1074      1     1074  1074.00      6 HASH(rr_Josi_DurationTimer)
             tmr-CUL_HM_respPendTout      respPend:1A959E    889      4      903   225.75   1256 respPend:1A959E
          tmr-ROOMMATE_DurationTimer      HASH(0x17df160)    888      1      888   888.00      4 HASH(rr_Josi_DurationTimer)
                       FileLog_LED16          FileLog_Log    598      9      606    67.33      0 HASH(FileLog_LED16); HASH(LED16)
                      heizung_gesamt     structure_Notify    576     54     2031    37.61      0 HASH(heizung_gesamt); HASH(az_heizung)
          tmr-ROOMMATE_DurationTimer      HASH(0x2fae4a0)    517      1      517   517.00      4 HASH(rr_Josi_DurationTimer)
          tmr-ROOMMATE_DurationTimer      HASH(0x17ca818)    513      1      513   513.00   3947 HASH(rr_Josi_DurationTimer)
    FileLog_CUL_HM_HM_CC_RT_DN_31354          FileLog_Log     98      2       99    49.50      0 HASH(FileLog_CUL_HM_HM_CC_RT_DN_31354); HASH(CUL_HM_HM_CC_RT_DN_31354C)
         tmr-PRESENCE_StartLocalScan      HASH(0x26cd9d8)     72      7      290    41.43   3697 HASH(josi.handy)
         tmr-PRESENCE_StartLocalScan      HASH(0x26bb0f0)     71      7      326    46.57   3169 HASH(alex.handy)
         tmr-PRESENCE_StartLocalScan      HASH(0x28b25c8)     58      7      233    33.29   4012 HASH(alex.PC)
         tmr-PRESENCE_StartLocalScan      HASH(0x28b2088)     26      7      127    18.14   4085 HASH(josi.PC)
                 telnetForBlockingFn          telnet_Read     17     31      124     4.00      0 HASH(telnetForBlockingFn)
                       battery_check          notify_Exec     16     54       68     1.26      0 HASH(battery_check); HASH(fl_rauchmelder)
                 tmr-HMLAN_KeepAlive     keepAlive:HMLAN1     16     10       44     4.40   2612 keepAlive:HMLAN1
                       wz_thermostat           CUL_HM_Set     16      2       26    13.00      0 HASH(wz_thermostat); wz_thermostat; ?
          tmr-FRITZBOX_Readout_Start     FritzBox.Readout     15      1       15    15.00      5 FritzBox.Readout
RasPi mit HMLAN, 5x HM-SEC-SC, HM LED16 als Alarmanlagendisplay, HM-TC-IT-WM-W-EU, 4x HM-CC-RT-DN, 1x HM PBU, 1x HM PBI-4

selfarian

#21
15 April 2015, 20:24:49
Ok, jetzt habe ich ein anderes Problem. Ich habe etwas aufgeräumt, also meine alte Alarmanlagen-Schaltung rausgeschmissen und ein paar httpmods. Also alles übers Webinterface per delete ... .
Jetzt schmiert mir FHEM ab. Im Log finde ich:
Code Auswählen
2015.04.15 17:52:37 1: PERL ERROR: Can't locate Authen/SASL/XS.pm in @INC (@INC contains: ./FHEM/lib ./lib /etc/perl /usr/local/lib/perl/5.14.2 /usr/local/share/perl/5.14.2 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.14 /usr/share/perl/5.14 /usr/local/lib/site_perl . ./FHEM) at (eval 3415) line 2.

2015.04.15 17:52:37 3: stacktrace:
2015.04.15 17:52:37 3:     main::__ANON__                      called by (eval 3415) (2)
2015.04.15 17:52:37 3:     (eval)                              called by /usr/share/perl5/Authen/SASL.pm (76)
2015.04.15 17:52:37 3:     Authen::SASL::client_new            called by /usr/share/perl5/XML/Stream.pm (2155)
2015.04.15 17:52:37 3:     XML::Stream::SASLClient             called by /usr/share/perl5/Net/XMPP/Protocol.pm (1958)
2015.04.15 17:52:37 3:     Net::XMPP::Protocol::AuthSASL       called by /usr/share/perl5/Net/XMPP/Protocol.pm (1807)
2015.04.15 17:52:37 3:     Net::XMPP::Protocol::AuthSend       called by ./FHEM/99_myUtils.pm (66)
2015.04.15 17:52:37 3:     main::GoogleTalk                    called by (eval 3405) (1)
2015.04.15 17:52:37 3:     (eval)                              called by fhem.pl (917)
2015.04.15 17:52:37 3:     main::AnalyzePerlCommand            called by fhem.pl (937)
2015.04.15 17:52:37 3:     main::AnalyzeCommand                called by fhem.pl (869)
2015.04.15 17:52:37 3:     main::AnalyzeCommandChain           called by ./FHEM/91_watchdog.pm (145)
2015.04.15 17:52:37 3:     main::watchdog_Trigger              called by fhem.pl (2574)
2015.04.15 17:52:37 3:     main::HandleTimeout                 called by fhem.pl (540)
2015.04.15 17:52:40 1: CallBlockingFn: Can't connect to localhost:47533: IO::Socket::INET: connect: Verbindungsaufbau abgelehnt
2015.04.15 17:52:40 1: PERL ERROR: Can't use an undefined value as a symbol reference at FHEM/Blocking.pm line 125.

2015.04.15 17:52:40 3: stacktrace:
2015.04.15 17:52:40 3:     main::__ANON__                      called by FHEM/Blocking.pm (125)
2015.04.15 17:52:40 3:     main::BlockingInformParent          called by FHEM/Blocking.pm (94)
2015.04.15 17:52:40 3:     main::BlockingCall                  called by ./FHEM/73_PRESENCE.pm (535)
2015.04.15 17:52:40 3:     main::PRESENCE_StartLocalScan       called by fhem.pl (2574)
2015.04.15 17:52:40 3:     main::HandleTimeout                 called by fhem.pl (540)
RasPi mit HMLAN, 5x HM-SEC-SC, HM LED16 als Alarmanlagendisplay, HM-TC-IT-WM-W-EU, 4x HM-CC-RT-DN, 1x HM PBU, 1x HM PBI-4

martinp876

#22
18 April 2015, 06:59:33
das presence modul macht einen (wohl internen) aufruf einer Hintergrundaktion Blocking. Die geht schief, weil etwas fehlt.
Also Presence untersuchen - ggf alles davon rausschmeißen und probieren

selfarian

#23
19 April 2015, 20:52:58
Ok, danke. Das Presence-Problem hat sich jetzt wohl erledigt. Ich hatte Verbose Logging auf 4 gestellt und seitdem trat es nichtmehr auf. Ich bin mir unsicher, ob ich in dem Zuge auch den RPi neugestartet habe und es vielleicht damit zusammen hängt, das der sich irgendwie verschluckt hat.
Das Problem mit den HMLAN disconnects besteht aber leider weiterhin :/
Ich weiß nicht, ob es Sinn macht, den RPi platt zu machen und alles neu zu installieren :/
RasPi mit HMLAN, 5x HM-SEC-SC, HM LED16 als Alarmanlagendisplay, HM-TC-IT-WM-W-EU, 4x HM-CC-RT-DN, 1x HM PBU, 1x HM PBI-4

frank

#24
20 April 2015, 16:22:47
ZitatDas Problem mit den HMLAN disconnects besteht aber leider weiterhin :/
Ich weiß nicht, ob es Sinn macht, den RPi platt zu machen und alles neu zu installieren :/
eher nicht, würde ich behaupten.

Code Auswählen
logdb            DbLog_Log   6636     54    52877   979.20      0 HASH(logdb); HASH(wz_heizung)

überprüfe mal deine datenbank.
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

selfarian

#25
20 April 2015, 18:03:23
Vielleicht lag es daran. Ich habe den Sprung ins kalte und unangenehme Wasser gewagt und habe den RPi komplett platt gemacht, neu installiert und bis jetzt funktioniert alles recht gut. Habe ein paar Empfangsprobleme jetzt gehabt, aber die kriege ich dann wahrscheinlich in den Griff, wenn ich mit dem HMLAN weiter ins Zentrum des Hauses vorrücke. Zumindest bisher keine Disconnects von HMLAN.
RasPi mit HMLAN, 5x HM-SEC-SC, HM LED16 als Alarmanlagendisplay, HM-TC-IT-WM-W-EU, 4x HM-CC-RT-DN, 1x HM PBU, 1x HM PBI-4

selfarian

#26
24 April 2015, 23:00:34
Wie kann denn sowas sein? Habe heute meinen neuen hm-sec-sc2 ausgepackt, gepaired, getConfig, alles ok, dann mit meinem Heizungsthermostat gepeered (windowRec Channel) und das kam dabei raus:
Code Auswählen
Internals:
   DEF        236BCB03
   NAME       HM_236BCB_WindowRec
   NR         52
   STATE      last:og.sz.fenster :closed
   TYPE       CUL_HM
   chanNo     03
   device     HM_236BCB
   peerList   og.sz.fenster,
   Readings:
     2015-04-24 22:50:48   R-og.sz.fenster_chn-01-shCtValLo 50
     2015-04-24 22:50:48   R-og.sz.fenster_chn-01-winOpnTemp 12 C
     2015-04-20 16:49:35   R-sign          off
     2015-04-24 22:50:47   RegL_01:          08:00 00:00
     2015-04-24 22:50:48   RegL_03:og.sz.fenster_chn:01   04:32 00:00
     2015-04-24 22:50:48   RegL_07:og.sz.fenster_chn:01   05:18 00:00
     2015-04-24 22:50:47   peerList        og.sz.fenster,
     2015-04-23 15:01:39   state           unpeered
     2015-04-24 22:57:39   trigLast        og.sz.fenster :closed
     2015-04-24 22:57:39   trig_og.sz.fenster closed
   Helper:
     peerIDsRaw ,31BB9401,00000000
     Role:
       chn        1
     Shadowreg:
Attributes:
   model      HM-CC-RT-DN
   peerIDs    00000000,31BB9401,
   stateFormat last:trigLast

Das state           unpeered  wundert mich...
RasPi mit HMLAN, 5x HM-SEC-SC, HM LED16 als Alarmanlagendisplay, HM-TC-IT-WM-W-EU, 4x HM-CC-RT-DN, 1x HM PBU, 1x HM PBI-4

Pfriemler

#27
25 April 2015, 02:36:03
Mich auch. Das Reading mit der Peerlist vom Sensor ist aber von 22:50, der state von 15:01, vielleicht also noch von vor dem Peeren. Seltsam.
"Änd're nie in fhem.cfg, denn das tut hier allen weh!" *** Wheezy@Raspi(3), HMWLAN+HMUART, CUL868(SlowRF) für FHT+KS+FS20, miniCUL433, Rademacher DuoFern *** "... kaum macht man es richtig, funktioniert es ..."

selfarian

#28
25 April 2015, 08:53:45
Stimmt. Komisch ist, das ich den Sensor ja erst gestern ausgepackt habe, also er am 23. noch Batterielos in der Verpackung lag...
RasPi mit HMLAN, 5x HM-SEC-SC, HM LED16 als Alarmanlagendisplay, HM-TC-IT-WM-W-EU, 4x HM-CC-RT-DN, 1x HM PBU, 1x HM PBI-4

martinp876

#29
25 April 2015, 11:37:16
das ist so eine Sache....
der state des winrec könnte "unpeered" sein, wenn er nicht gepeert ist.
ist er gepeert wird bei WinRec NICHT peered geschrieben. Grund: ein gepeerter WinRec sollte als state open oder closed haben. das soll nicht überschrieben werden.

Es gibt also channels, die nur peered/unpeered haben und solche, die, wenn gepeert einen anderen State bereitstellen. Hier werden ich wohl besser "unknown" schreiben.
Drucken
Nach oben Seiten 1 2 3 Alle
Benutzer-Aktionen