RPI gegen schnelleren Server ersetzen

[Gunther]

Könnt Ihr mir helfen zu entscheiden, ob und wenn ja wie ich upgrade?

Derzeit läuft mein FHEM auf einem RPI3. Ich habe immer mal wieder Bedenkzeiten.
Ggf. auch bedingt durch Installationskram (z. B. abgebrochene Alexa-Installation).

Wenn ich FHEM neu aufsetze, überlege ich das auf eine Plattform mit mehr Power zu machen. Auf mein Synology will ich nicht, da ich nicht zwei Geräte die ich brauche in einem verbinden will.

Welche möglichst energiesparenden Alternativen kommen in Frage - und warum? Hier sehe ich den Wald vor lauter Bäumen nicht mehr (Banana Pi Cubi, BeagleBone, etc.)
Machen die für mich als Linux-Anfänger Sinn oder bin ich dann aufgeschmissen, wenn mal was nicht geht?

[KernSani]

Die Frage, die ich mir zunächst stellen würde ist, wieso ein RPI3 nicht ausreichend ist. Wie groß ist denn deine Installation und gibt es nicht Optionen da was zu optimieren?

[LuckyDay]

(Banana Pi Cubi, BeagleBone, etc.)

Das ist aber alte Hardware , und auch keine Einfache.
, und wenn du mit dem PI3 nicht klarkommst, ist nicht mehr viel Luft nach unten.
das steht aber etwas mehr in Bezug auf deutschsprachige Foren usw , Anleitungen. bist du noch bei Jessi oder schon auf stretch unterwegs. stretch empfehle ich nicht für Anfänger, tut vieles nicht so wie gewünscht.

[Gunther]

also wird was schnelleres als der RPI nicht so einfach?

Ich bin noch auf Jessi. Englisch kein Problem.

[LuckyDay]

also wird was schnelleres als der RPI nicht so einfach?

Ich bin noch auf Jessi. Englisch kein Problem.

das widerspricht sich zu dem-->

möglichst energiesparenden Alternativen

schau dich bei  NUC 's z-box usw um
https://forum.fhem.de/index.php/topic,77356.0.html

[schnitzelbrain]

Dann schau dir doch mal die Hardware von dieser Seite an
https://wiki.fhem.de/wiki/ODROID_XU4



Schnitzelbrain

[CoolTux]

Malals krasses Gegenstück. Ich habe hier einen RPI2b+ und er langweilt sich fast. Mein FHEM Umfasst 585 Definitionen, davon alleine 60 Homematic Produkte.
Mein FHEM läuft und läd fließend.

[Gunther]

Wo finde ich die Anzahl der Definitionen?

Bei mir laufen bestimmt einige inperformant aufgesetzte DOIFs und notifying 😂

[CoolTux]

Nach dem FHEM Start steht im Log die Anzahl der Definitionen. Die haben zwar erstmal keine große Aussagekraft, kommt ja immer drauf an was da wie definiert ist, aber nur um mal zu schauen ist das schon mal ok.

[MadMax-FHEM]

Wo finde ich die Anzahl der Definitionen?

Bei mir laufen bestimmt einige inperformant aufgesetzte DOIFs und notifying 😂

Oder genauer mittels 'fheminfo' dann sieht man auch wieviel wovon...

https://fhem.de/commandref.html#fheminfo

Gruß, Joachim

[CoolTux]

Stimmt. Geht ja auch seit ein paar Monaten

Code Auswählen Erweitern


System Info
ConfigType: configDB
SVN rev: 15747
OS: linux
Perl: 5.24.1
uniqueId: 880...

Modules Model Count
AMADCommBridge 1
AMADDevice 8
CUL_HM
HM-LC-SW1-PL2 1
HM-LC-Sw1PBU-FM 5
HM-LC-SW1-BA-PCB 2
HM-PB-2-WM55-2 1
ActionDetector 1
HM-WDS40-TH-I 4
HM-ES-TX-WM 1
HM-Dis-WM55 1
HM-WDS40-TH-I-2 1
HM-CC-RT-DN 5
CCU-FHEM 1
HM-SEC-SD-2 7
HM-LC-Dim1TPBU-FM 2
HM-TC-IT-WM-W-EU 1
HM-SEC-SC-2 4
HM-PB-6-WM55 1
HM-LC-SW1-FM 1
HM-SEC-RHS 8
HM-ES-PMSw1-Pl 6
DOIF 18
DbLog
MYSQL 2
FB_CALLLIST 1
FB_CALLMONITOR 1
FHEM2FHEM 1
FHEMWEB 3
FRITZBOX 1
FileLog 1
GUEST 1
HMLAN 1
HMUARTLGW
HM-MOD-UART 1
HMinfo 1
HMtemplate 1
HOMBOT 1
HTTPMOD 1
HUEBridge 1
HUEDevice 2
LLC010 1
LCT001 7
LLC020 2
LST001 4
LightScene 1
PLAYBULB
BTL300_v5 6
BTL400M_v18 1
PRESENCE
lan-bluetooth 5
lan-ping 4
function 2
PROPLANTA 1
Pushover 1
RESIDENTS 3
ROOMMATE 4
SVG 12
SYSMON 1
SmarterCoffee 1
TRX 1
TRX_LIGHT 12
TRX_WEATHER 4
Twilight 1
UWZ 1
UbiquitiMP 1
UbiquitiOut 6
Weather 1
XiaomiFlowerSens 3
allowed 2
at 13
autocreate 1
cloneDummy 6
configDB
MYSQL (b64) 1
dewpoint 2
dummy 34
eventTypes 1
holiday 1
msgConfig 1
notify 89
readingsGroup 19
readingsProxy 17
sequence 1
statistics 1
structure 32
telnet 1
watchdog 43
weblink 1


Hier mal eine Übersicht meiner Hauptinstanz.

[blecher-at]

FHEM ist singlethreaded. d.h. wenn deine doifs/notifys inperformant (sleeps ahoi) sind, wirst sich selbst auf einem supercomputer keine performanceverbesserung ergeben.

[MadMax-FHEM]

Wenn der sleep ein "fhem sleep" ist, ist das unproblematisch...

Beim Rest stimme ich zu...
...Performance nur über HW...

Kann man machen...
...oder lassen und dann lieber richtig machen...

Gruß, Joachim

[Beta-User]

Würde auch eher erst mal nach Performance-Killern suchen, Stichworte: apptime und perfmon.

FHEM ist singlethreaded. d.h. wenn deine doifs/notifys inperformant (sleeps ahoi) sind, wirst sich selbst auf einem supercomputer keine performanceverbesserung ergeben.

Stimmt zwar, aber die Limitierung des gesamten Datenverkehrs über USB zum Prozessor ist schon was, was den Pi gg. anderen Lösungen ausbremst (Plots und so), aber das kann man noch verschmerzen. Es gibt aber gute andere Gründe, dem Pi zu entsagen (angefangen von der ungleich höheren Lebensdauer von SSD's gg. SD-Karten).

Was die Linux-Installation angeht, würde ich ggf. "normale" PC-Hardware empfehlen, alles andere _kann_ zum Gefrickel werden. Dabei nicht unbedingt die aller-aktuellste Hardware nehmen und nach Möglichkeit was, bei dem die HW ordentlich dokumentiert ist.
(z.B. NUC, zbox, Brix, am besten passiv gekühlt).

Die Debian-Installation auf einem ThinClient (Atom, 12,x W im FHEM-Betrieb mit 5 USB-IO's) habe ich im Wiki dargestellt, sollte auf o.g. Plattformen genauso gehen.

[Gunther]

Ob ich eine große Installation habe, kann ich nicht beurteilen. Da kommt eine Menge zusammen.

Code Auswählen Erweitern

Server started with 1110 defined entities

fheminfo:

Code Auswählen Erweitern

System Info
ConfigType: configFile
SVN rev: 15760
OS: linux
Perl: 5.14.2
uniqueId: b47...

Modules Model Count
ABFALL 1
AMADCommBridge 1
AMADDevice 4
CALVIEW 1
CM160 1
CUL 1
CUL_FHTTK 8
CUL_HM
HM-LC-Sw1PBU-FM 2
HM-SEC-MDIR 2
HM-SEC-SC 6
HM-LC-SW4-DR 1
HM-SEC-SC-2 8
HM-LC-SW1-FM 12
HM-SEC-RHS 2
HM-RC-19-SW 1
HM-SEC-WDS-2 1
CCU-FHEM 1
HM-RC-KEY3 1
HM-SEC-MDIR-2 1
HM-RC-4-2 1
HM-ES-PMSw1-Pl 6
HM-LC-Bl1PBU-FM 8
HM-CC-RT-DN 11
HM-LC-SW4-WM 1
HM-TC-IT-WM-W-EU 11
HM-WDS30-OT2-SM 5
HM-LC-BL1-FM 3
HM-LC-Dim1TPBU-FM 4
HM-PB-6-WM55 5
HM-LC-DIM1T-FM 11
HM-LC-Sw1-DR 4
HM-LC-SW1-BA-PCB 1
HM-SEC-SD-2 8
ActionDetector 1
HM-LC-Dim1PWM-CV 6
CUL_WS 2
S300TH 1
Calendar 2
DOIF 44
ENIGMA2
Duo² 1
FB_CALLLIST 1
FB_CALLMONITOR 1
FHEMWEB 3
FHT 8
FLOORPLAN 2
FRITZBOX 2
FS20 10
FileLog 178
HMLAN 4
HMinfo 1
HTTPSRV 3
HUEBridge 1
HUEDevice 21
FLS-PP3 White 9
FLS-PP3 9
JeeLink 1
LaCrosse 5
LightScene 26
MilightBridge 1
MilightDevice 7
ONKYO_AVR
pre2013 1
PROPLANTA 1
Pushover 1
SVG 27
Spotify 1
TRAFFIC 15
Twilight 1
VBUSDEV
Vitosolic200 1
VBUSLAN 1
VCONTROL 1
Verkehrsinfo 1
WOL 9
Weather 1
WeekdayTimer 1
ZWDongle 2
ZWave
FIBARO System FGMS001-ZW5 Motion Sensor 3
FIBARO System FGMS001 Motion Sensor 2
FIBARO System FGWPE/F Wall Plug Gen5 1
at 9
autocreate 1
dewpoint 2
dummy 143
eventTypes 1
fakeRoku 1
harmony 10
holiday 1
monitoring 2
notify 106
readingsGroup 6
statistics 4
structure 16
telnet 1
weblink 2

44 DOIF und 106 notify. Über 120 HomeMatic Geräte. Wenig, viel, normal?

Hier mal ein wahlloser Auszug aud der fhem.log bzgl. perfmon. Ist das normal, dass jeder zweite Eintrag perfmon ist? 

Code Auswählen Erweitern

2018.01.03 14:52:46 1: Perfmon: possible freeze starting at 14:52:44, delay is 2.791
2018.01.03 14:52:53 1: Perfmon: possible freeze starting at 14:52:51, delay is 2.177
2018.01.03 14:53:08 1: Perfmon: possible freeze starting at 14:53:06, delay is 2.606
2018.01.03 14:53:30 1: Perfmon: possible freeze starting at 14:53:28, delay is 2.168
2018.01.03 14:53:39 1: Perfmon: possible freeze starting at 14:53:37, delay is 2.947
2018.01.03 14:53:41 1: Timeout for MilightBridge_DoPing reached, terminated process 6594
2018.01.03 14:53:41 3: BlockingCall for eg_ki_MilightBridge_Leuchtkaesten was aborted
2018.01.03 14:53:46 1: Perfmon: possible freeze starting at 14:53:44, delay is 2.741
2018.01.03 14:53:54 1: Timeout for MilightBridge_DoPing reached, terminated process 6595
2018.01.03 14:53:54 3: BlockingCall for eg_ki_MilightBridge_Leuchtkaesten was aborted
2018.01.03 14:54:06 1: Timeout for MilightBridge_DoPing reached, terminated process 6624
2018.01.03 14:54:06 3: BlockingCall for eg_ki_MilightBridge_Leuchtkaesten was aborted
2018.01.03 14:54:09 1: Perfmon: possible freeze starting at 14:54:08, delay is 1.022
2018.01.03 14:54:22 1: PERL WARNING: Use of uninitialized value $value in string eq at fhem.pl line 4398.
2018.01.03 14:54:31 3: ABFALL myAbfall - CALENDAR:Abfall triggered, updating ABFALL myAbfall ...
2018.01.03 14:54:31 3: ABFALL_UPDATE
2018.01.03 14:54:31 1: Perfmon: possible freeze starting at 14:54:30, delay is 1.642
2018.01.03 14:54:46 1: Perfmon: possible freeze starting at 14:54:44, delay is 2.263
2018.01.03 14:54:54 1: Perfmon: possible freeze starting at 14:54:52, delay is 2.611
2018.01.03 14:55:30 1: Perfmon: possible freeze starting at 14:55:28, delay is 2.769
2018.01.03 14:55:41 1: Perfmon: possible freeze starting at 14:55:39, delay is 2.601
2018.01.03 14:55:43 1: Perfmon: possible freeze starting at 14:55:42, delay is 1.294
2018.01.03 14:55:46 1: Perfmon: possible freeze starting at 14:55:45, delay is 1.292
2018.01.03 14:55:49 1: Perfmon: possible freeze starting at 14:55:47, delay is 2.4
2018.01.03 14:56:46 1: Perfmon: possible freeze starting at 14:56:44, delay is 2.784
2018.01.03 14:56:56 1: Perfmon: possible freeze starting at 14:56:54, delay is 2.676
2018.01.03 14:57:03 1: Perfmon: possible freeze starting at 14:57:02, delay is 1.332
2018.01.03 14:57:30 1: Perfmon: possible freeze starting at 14:57:28, delay is 2.148
2018.01.03 14:57:41 1: Perfmon: possible freeze starting at 14:57:39, delay is 2.72
2018.01.03 14:57:43 1: Perfmon: possible freeze starting at 14:57:42, delay is 1.124
2018.01.03 14:57:48 1: Perfmon: possible freeze starting at 14:57:46, delay is 2.604
2018.01.03 14:58:30 1: Timeout for MilightBridge_DoPing reached, terminated process 6839
2018.01.03 14:58:30 3: BlockingCall for eg_ki_MilightBridge_Leuchtkaesten was aborted
2018.01.03 14:58:46 1: Perfmon: possible freeze starting at 14:58:44, delay is 2.309
2018.01.03 14:58:57 1: Perfmon: possible freeze starting at 14:58:55, delay is 2.578
2018.01.03 14:59:30 1: Perfmon: possible freeze starting at 14:59:28, delay is 2.312
2018.01.03 14:59:42 1: Perfmon: possible freeze starting at 14:59:40, delay is 2.548
2018.01.03 14:59:46 1: Perfmon: possible freeze starting at 14:59:44, delay is 2.752
2018.01.03 14:59:56 1: Perfmon: possible freeze starting at 14:59:55, delay is 1.422
2018.01.03 15:00:07 2: harmony: disconnect
2018.01.03 15:00:10 1: Perfmon: possible freeze starting at 14:59:57, delay is 13.879
2018.01.03 15:00:11 3: harmony: connected
2018.01.03 15:00:13 1: Perfmon: possible freeze starting at 15:00:11, delay is 2.861
2018.01.03 15:00:13 1: Timeout for MilightBridge_DoPing reached, terminated process 6932
2018.01.03 15:00:13 3: BlockingCall for eg_ki_MilightBridge_Leuchtkaesten was aborted
2018.01.03 15:00:15 1: Perfmon: possible freeze starting at 15:00:14, delay is 1.5
2018.01.03 15:00:16 1: Timeout for WOL_Ping reached, terminated process 6934
2018.01.03 15:00:16 3: BlockingCall for Epson830 was aborted
2018.01.03 15:00:16 1: Timeout for WOL_Ping reached, terminated process 6935
2018.01.03 15:00:16 3: BlockingCall for DS2413 was aborted
2018.01.03 15:00:16 1: Timeout for WOL_Ping reached, terminated process 6936
2018.01.03 15:00:16 3: BlockingCall for InoKeyFingerprint2 was aborted
2018.01.03 15:00:16 1: Timeout for WOL_Ping reached, terminated process 6937
2018.01.03 15:00:16 3: BlockingCall for MacBookPro2017 was aborted
2018.01.03 15:00:16 1: Timeout for WOL_Ping reached, terminated process 6938
2018.01.03 15:00:16 3: BlockingCall for winserver was aborted
2018.01.03 15:00:20 3: harmony: new config

[CoolTux]

Die  possible freeze sind nicht gut. Das sind ganz schön viele nacheinander. Das solltest Du Dir mal genauer anschauen.

[Beta-User]

(Cooltux war mal wieder schneller):

Die Installation kommt mir jetzt nicht sooo groß vor, es kommt aber natürlich auch darauf an, wie das im einzelnen tickt (wenn Geräte viele Events werfen, ist ein Eventhandler wie notify halt mehr beschäftigt...

Und was ein Dummy macht bzw. wofür man ihn wirklich braucht, war nochmal eine andere Geschichte .

Zum eigentlichen Thema: die (m.E.) erhebliche Anzahl der perfmon-Meldungen ist nicht normal (wenn man davon absieht, dass Milight-Bridges dieses gerne verursachen, you were warned...)

Ich würde also als erstes die Milight-Definitionen auf Wifilight umstellen.

Dann den Müllkalender: Ziehst du den regelmäßig aus dem Netz? => runterladen und als file einbinden...

usw.

Gruß, Beta-User

[KernSani]

Ich denke auch es wird ein bisschen viel geloggt... 178 FileLogs bei 27 SVGs passt m. E. nicht ganz... allerdings keine Ahnung ob das die Performance beeinträchtigt...

[CoolTux]

Mich würde Mal der Eventmonitor interessieren. Das muss ja nur so durch rattern.

[Gunther]

Hier mal ein Auszug aus apptime:

Code Auswählen Erweitern

active-timers: 92; max-active timers: 106; max-timer-load: 19  min-tmrHandlingTm: 1.3ms; max-tmrHandlingTm: 17699.3ms; totAvgDly: 899.2ms
min-timersortTm: 1.2ms; max-timersortTm: 9.1ms

name                                     function                               max    count      total  average   maxDly   avgDly TS Max call     param Max call
tmr-statistics_PeriodChange              HASH(0x4d22dd8)                      12850        1   12850.22 12850.22  3319.03  3319.03 04.01. 16:00:11 HASH(stat_temperature_humidity)
vbus                                     VBUSLAN_Read                          3937    29832 1271786.81    42.63     0.00     0.00 04.01. 15:08:44 HASH(vbus)
tmr-harmony_connect                      HASH(0x3638cb8)                       3013      237  708368.52  2988.90 10657.78   631.02 04.01. 15:43:16 HASH(harmony)
HMLAN1                                   HMLAN_Read                            2825     1330  386253.80   290.42     0.00     0.00 04.01. 15:10:52 HASH(HMLAN1)
doif_KaminStatus                         DOIF_Notify                           2258     9798  711188.98    72.59     0.00     0.00 04.01. 15:36:13 HASH(doif_KaminStatus); HASH(VBUSDEV_7321)
harmony                                  harmony_Read                          2085       59    2165.83    36.71     0.00     0.00 04.01. 16:02:24 HASH(harmony)
HMLAN2                                   HMLAN_Read                            2083     1264  133047.19   105.26     0.00     0.00 04.01. 15:35:38 HASH(HMLAN2)
StatusKamin                              dummy_Set                             1958     2103  605415.36   287.88     0.00     0.00 04.01. 15:36:12 HASH(StatusKamin); StatusKamin; brennt
myJeeLink                                JeeLink_Read                          1834     3616  402974.93   111.44     0.00     0.00 04.01. 15:47:54 HASH(myJeeLink)
HMLAN3                                   HMLAN_Read                            1792     1160   77063.98    66.43     0.00     0.00 04.01. 15:42:00 HASH(HMLAN3)
HMLAN4                                   HMLAN_Read                            1555     1230   94162.64    76.55     0.00     0.00 04.01. 15:51:49 HASH(HMLAN4)
doif_Kamin_Holz_nachlegen                DOIF_Notify                           1332     9798  795300.26    81.17     0.00     0.00 04.01. 15:36:12 HASH(doif_Kamin_Holz_nachlegen); HASH(StatusKamin)
CUL_0                                    CUL_Read                              1275      332   70935.64   213.66     0.00     0.00 04.01. 15:18:00 HASH(CUL_0)
Holz_nachlegen                           dummy_Set                             1026     4052  590407.19   145.71     0.00     0.00 04.01. 15:36:12 HASH(Holz_nachlegen); Holz_nachlegen; nein
doif_tabletlademanagement_og_bz          DOIF_Notify                            947     9798    3185.65     0.33     0.00     0.00 04.01. 15:19:18 HASH(doif_tabletlademanagement_og_bz); HASH(og_bz_Tablet10Zoll)
stat_temperature_humidity                statistics_Notify                      919     9798   63622.72     6.49     0.00     0.00 04.01. 16:38:17 HASH(stat_temperature_humidity); HASH(og_bz_Wandthermostat_Climate)
Viessmann                                VCONTROL_Read                          749     2616   50640.15    19.36     0.00     0.00 04.01. 16:32:18 HASH(Viessmann)
doif_kaminstatus_gesamt                  DOIF_Notify                            648     9798  398118.08    40.63     0.00     0.00 04.01. 16:27:58 HASH(doif_kaminstatus_gesamt); HASH(Holz_nachlegen)
ls_licht_og_bz                           LightScene_Notify                      644     9798    3204.56     0.33     0.00     0.00 04.01. 16:28:11 HASH(ls_licht_og_bz); HASH(og_bz_licht_deckenspots)
tmr-CUL_HM_respPendTout                  respPend                               640       12    1725.46   143.79  3272.36   685.23 04.01. 16:06:24 respPend:23A83F
tmr-statistics_PeriodChange              HASH(0x4d22e98)                        634        1     634.07   634.07  2070.29  2070.29 04.01. 15:59:57 HASH(stat_Viessmann)
tmr-statistics_PeriodChange              HASH(0x4d457d0)                        613        1     613.41   613.41  2704.91  2704.91 04.01. 15:59:58 HASH(STATISTICS)
ls_licht_eg_ez                           LightScene_Notify                      599     9798    1388.82     0.14     0.00     0.00 04.01. 16:14:48 HASH(ls_licht_eg_ez); HASH(eg_ez_kronleuchter)
og_bz_4erSchalter_Sw_02_Tablet           CUL_HM_Set                             598       13     622.73    47.90     0.00     0.00 04.01. 15:19:18 HASH(og_bz_4erSchalter_Sw_02_Tablet); og_bz_4erSchalter_Sw_02_Tablet; on
ls_licht_eg_fl                           LightScene_Notify                      589     9798    1881.27     0.19     0.00     0.00 04.01. 16:15:28 HASH(ls_licht_eg_fl); HASH(eg_fl_licht_treppenhaus)
structure_lichtstatus_eg_ez              structure_Notify                       569     9798    1430.31     0.15     0.00     0.00 04.01. 16:14:48 HASH(structure_lichtstatus_eg_ez); HASH(eg_ez_kronleuchter)
tmr-at_Exec                              HASH(0x2d92608)                        528     1093  319008.33   291.86 19190.27  1009.71 04.01. 16:23:34 HASH(WattUsageAnDummy)
Geburtstage                              CALVIEW_Notify                         498     9798    1880.48     0.19     0.00     0.00 04.01. 15:45:02 HASH(Geburtstage); HASH(GeburtstagsKalender)
Fenster_monitoring                       monitoring_Notify                      479     9798 2127867.06   217.17     0.00     0.00 04.01. 16:06:14 HASH(Fenster_monitoring); HASH(kg_fl_Eisschrank)
tmr-Spotify_poll                         HASH(0x4175220)                        479       18     780.78    43.38  3719.93  1108.17 04.01. 15:59:45 HASH(Spotify_Gunther)
stat_Viessmann                           statistics_Notify                      430     9798   28289.99     2.89     0.00     0.00 04.01. 16:33:38 HASH(stat_Viessmann); HASH(Viessmann)
tmr-Twilight_sunpos                      HASH(0x5495980)                        373        1     373.68   373.68  2097.74  2097.74 04.01. 15:09:34 HASH(au_blaue_Stunde_sunpos)
myAbfall                                 ABFALL_Notify                          369     9798    4815.04     0.49     0.00     0.00 04.01. 16:27:33 HASH(myAbfall); HASH(Abfall)
STATISTICS                               statistics_Notify                      363     9798    9679.40     0.99     0.00     0.00 04.01. 15:40:23 HASH(STATISTICS); HASH(Aussentemperatur)
tmr-Twilight_fireEvent                   HASH(0x546c6e0)                        355        1     355.56   355.56   432.95   432.95 04.01. 15:57:50 HASH(au_blaue_Stunde_ss_weather)
stat_StatusKamin                         statistics_Notify                      353     9798  108012.36    11.02     0.00     0.00 04.01. 16:04:43 HASH(stat_StatusKamin); HASH(StatusKamin)
tmr-Twilight_sunpos                      HASH(0x6ee5df8)                        351        1     351.52   351.52  1678.77  1678.77 04.01. 16:09:48 HASH(au_blaue_Stunde_sunpos)
Status_Kamin_gesamt                      dummy_Set                              332     4052  193263.83    47.70     0.00     0.00 04.01. 16:27:58 HASH(Status_Kamin_gesamt); Status_Kamin_gesamt; brennt
tmr-CUL_HM_readStateTo                   sUpdt                                  328        3     592.34   197.45   290.58   192.86 04.01. 16:36:48 sUpdt:og_sz_JalousieLinks
tmr-Twilight_sunpos                      HASH(0x626c208)                        305        1     305.10   305.10   296.56   296.56 04.01. 15:14:34 HASH(au_blaue_Stunde_sunpos)
tmr-Twilight_sunpos                      HASH(0x6bfac78)                        303        1     303.97   303.97  1528.32  1528.32 04.01. 16:04:46 HASH(au_blaue_Stunde_sunpos)

Zu den Fragen:

Müllkalender: Ich habe einen eigenen google-Kalender den ich abfrage.

Milight: Habe gestern die letzten Geräte rausgeworfen, muss nur noch den ganzen Rotz aus meiner Installation löschen.

Die 178 FileLogs kommen dadurch, dass diese damals per autocreate bei mir immer mit angelegt wurden. Hier ist sicher Potential zum Aufräumen (vieles davon brauche ich sicherlich nicht).

Ja, der Eventmonitor rattert wild...

[Wernieman]

Ja, der Eventmonitor rattert wild...

Und genau das dürfte das Problem sein. Eine schnellere Hardware entspann zwar Dein Problem, aber es wird Grundsätzlich bestehen bleiben. Du müstest gucken, ob Du wirkliche alle Events brauchst ...

[Gunther]

Ich habe letztes Jahr meine Verletzungspause schon genutzt um aufzuräumen und event-on-change-readings .* bei vielen Devices zu setzen.
1) Wie gehe ich denn idealerweise vor zur Reduzierung der Events?

Unabhängig bin ich beim Beschäftigen eines Hardwareupgrades beim Nuc gelandet und würde gerne mehrere Fliegen mit einer Klappe erschlagen.
Dazu brauche ich aber mal Eure Meinung, ob das geht:
Nuc
darauf in virtuellen Maschinen:
- Linux mit FHEM
- Linux mit Kodi o.ä.
- Linux mit mysql (für FHEM, will zukünftig auf DBLog umstellen)
- Windows 7 oder Windows 10 (Ablösung meines Windows-"Servers", auf diesem läuft primär mein Onlinebanking - Wird nach Nutzung per FHEM runtergefahren)

Diese möchte ich gerne auf mein Synology, notfalls alternativ an eine angeschlossene externe Platte backuppen.

Dazu müsste ich natürlich etwas mehr in Hardware investieren.
2) Ist die Idee praktikabel?
3) Brauche ich dafür einen I5?
4) Sind 16 GB RAM ausreichend? (8 für Win, 8 für den Rest)
5) interne SSD: 250 GB (100 für Win, 150 für den Rest) ok?

Freue mich über Eure Meinungen.

[Wernieman]

Mag lieber die Zotac Reihe, da es dort bei einigen "ohne Lüfter" geht.

Abgesehen von Windows, kenne Deine Software nicht, brauchst Du keinen I5. Würde auch einen "kleineren" nehmen, da er im Dauerbetrieb häufig weniger Strom zieht. Vergiss nicht, das der Rechner 24+7 läuft. Mit dem Speicher sieht es genau so aus.

[Gunther]

habt Ihr Vergleichswerte von I3 und I5 Systemen bzgl. Stromverbrauch?

[Gunther]

habe hier etwas gefunden:

https://www.notebookcheck.com/Test-Intel-NUC5i3RYK-Mini-PC-Broadwell-Core-i3-5010U.147828.0.html

Die Leistungsaufnahme fällt für ein Desktop-System mit 6,4 bis 36 Watt sehr moderat aus und kann den Core i5 NUC im größeren Gehäuse (und mit stromhungrigerer 2,5-Zoll-SSD) noch deutlich hinter sich lassen (im Vergleich 7,6 bis 42,4 Watt).

Unter Vollast von Prime und Furmark erreicht der i3 NUC in den ersten Sekunden mit 36 Watt seine maximale Leistungsaufnahme. Diese senkt sich dann aber schnell auf moderate 26 Watt, da der i3-5010U zu throtteln beginnt. Auch bei Furmark ist dasselbe Phänomen sichtbar (von 33 auf 26,5 Watt), es ist also kein reines Prozessor-Throttling. Die Temperatur düfte nicht schuld sein, da die internen Sensoren in HWInfo 64 nur maximal 73 °C melden.

[Wernieman]

Wenn ikch denke, das mein Zotac bei der letzten Messung unter 7W verbrauchte ....

es ist allerdings ein  Intel(R) Celeron(R) CPU  N2930 ... der aber eigentlich meistens reicht. Weiß nur nicht, wie eine Windows VM das vertragen würde, eine Linux lief schon.

[Gunther]

Habe heute günstig einen nuc 7. Generation mit I3 in der Bucht ergattert. Bevor der zum Rennen kommt habe ich aber erstmal meine FHEM Problme zu lösen.

[maci]

Ich habe auch einen Pi 3 bei meiner FHEM Installation.
Ich betreibe ihn mit einer SSD anstatt der Karte.

Ich kenne die Wartezeiten auch, aber die kommen vor allem von den Plot-Grafiken.
Das ist mein Eindruck. Bei den Aufgaben habe ich keine Verzögerungen.

Ich glaube, dass man zu Beginn einfach zuviel und alles loggen will.
Daraus dann Plots erstellen. Das geht auf die Leistung.
Ich habe inzwischen begonnen, Plots aus meinen Räumen die ich oft brauche zu entfernen.
Bin draufgekommen, das dies zur schnellen Zustands-Überprüfung nichts bringt.
Wo ich Plots will, verschiebe ich diese, in einen eigenen Raum. Aber nicht alle Plots in einem Raum, denn sonst wartet man ewig bis dann etwas angezeigt wird.

Ich logge derzeit, wieder, in Logfiles, anstatt in die DB. Bin mir aber nicht sicher was besser ist.

[Gunther]

Ich habe zu viele Logs. Die recht wenigen Plots hängen in einem eigenen Raum.

[Frank_Huber]

Ich logge in eine DB. Hat für mich den Vorteil dass ich hier recht einfach bereinigen kann.

Immer mal wieder eine Liste der geloggten device/reading Kombinationen samt Anzahl rauslassen und alles unnötige löschen.

Ein nächster Schritt ist dann ältere Daten auf Tages / Stundendurchschnitt zu reduzieren.

Das alles ist mit logfiles eher nicht so einfach machbar wenn überhaupt.

Mit dem Handy online, daher kurz gefasst...

[Gunther]

Zur Sicherheit habe ich heute nochmal meine FHEM PI Version gecheckt.
Ich bin noch auf einem RPI2b unterwegs.
Erklärt das zum Teil die Freezes?

[Frank_Huber]

Zur Sicherheit habe ich heute nochmal meine FHEM PI Version gecheckt.
Ich bin noch auf einem RPI2b unterwegs.
Erklärt das zum Teil die Freezes?

Nein, mein system läuft auch auf pi2b.

Mit dem Handy online, daher kurz gefasst...

[Gunther]

danke.

Habe hier mal ein Thema aufgemacht für mein Dilemma:
https://forum.fhem.de/index.php?topic=82276.0

[Mave]

Ich habe auch einen Pi 3 bei meiner FHEM Installation.
Ich betreibe ihn mit einer SSD anstatt der Karte.

Ich kenne die Wartezeiten auch, aber die kommen vor allem von den Plot-Grafiken.
Das ist mein Eindruck. Bei den Aufgaben habe ich keine Verzögerungen.

Ich glaube, dass man zu Beginn einfach zuviel und alles loggen will.
Daraus dann Plots erstellen. Das geht auf die Leistung.
Ich habe inzwischen begonnen, Plots aus meinen Räumen die ich oft brauche zu entfernen.
Bin draufgekommen, das dies zur schnellen Zustands-Überprüfung nichts bringt.
Wo ich Plots will, verschiebe ich diese, in einen eigenen Raum. Aber nicht alle Plots in einem Raum, denn sonst wartet man ewig bis dann etwas angezeigt wird.

Ich logge derzeit, wieder, in Logfiles, anstatt in die DB. Bin mir aber nicht sicher was besser ist.

Hättest Du mir da eventuell eine gute Anleitung, wie man den RPI mit einer SSD Platte betreiben kann.

Mir geht es nicht um die Schnelligkeit sondern um die Ausfallsicherheit, die ja bei den SD-Karten nicht ganz so toll ist.

Vielen Dank.

[Bartimaus]

Hättest Du mir da eventuell eine gute Anleitung, wie man den RPI mit einer SSD Platte betreiben kann.

Mir geht es nicht um die Schnelligkeit sondern um die Ausfallsicherheit, die ja bei den SD-Karten nicht ganz so toll ist.

Vielen Dank.

Bitte:
https://raspberry.tips/raspberrypi-tutorials/raspberry-pi-von-ssd-festplatte-booten/

Wenn SD+SSD drin/dran ist, bootet der RPi3 von der SD, ist nur die SSD dran, bootet er von der SSD.

Habe ich gestern gemacht, geht wirklich fix.
Nur wenn ich das neue Image (Stretch-Lite) auf die SSD flashe, ignoriert dieser (Win32DiskImager) die vorab angelegten Partitionen auf der SSD.
ROOTFs hätte ich lieber auf einer 10GB Partition statt auf der ganzen 120er SSD. Mal sehen, ob ich das dann mit Gparted von einer LiveCD verkleinern kann.

[Mave]

Vielen Dank für Deine Rückmeldung.

Frage: Wenn ich den RPI auf USB Boot umstelle, kann ich dann gegebenenfalls wieder komplett auf SD Boot zurückstellen - falls es aus irgendeinem Grund mal nötig wäre? Wenn ich richtig verstanden habe, was OTP ist, dann kann ich nur einmal umkonfigurieren und dann nicht mehr.

Wenn Du mit eingelegter SD bootest, arbeitet der RPI dann mit der SSD Platte als Datenablage oder mit der SD Karte?

[Bartimaus]

Wenn Du mit eingelegter SD bootest, arbeitet der RPI dann mit der SSD Platte als Datenablage oder mit der SD Karte?

Nicht automatisch. Die SSD musst Du dann händisch(bis zum nächsten reboot) oder per FSTAB (dauerhaft) mounten.
Danach muss Du dem System (das von der SD) sagen, wofür die SSD als Datenablage genutzt werden soll.

[Mave]

Okay, verstanden.

Ich bevorzuge dann eher die Lösung mit der SSD Platte als einziges Medium.

Ist natürlich schon eine ganz schöne Platzverschwendung, ein 16 GB großes Image von der aktuellen SD Karte auf eine 128 GB große SSD Platte zu migrieren.

Dafür ist aber die Haltbarkeit eine andere....und eventuell auch die Geschwindigkeit.

[Bartimaus]

Code Auswählen Erweitern

sudo resize2fs -p /dev/gerätename 10G   # Vergrößert bzw. Verkleinert das Dateisystem auf 10 Gigabyte Gesamtgröße....

darf allerdings nicht gemountet sein.

[ToM_ToM]

Mein Pi langweilg sich auch die meiste Zeit.
Es kann jedoch vorkommen dass ein FHEM-Prozess solange zur Abarbeitung benötigt dass ich in der Zeit dann nicht mal ein Licht per Funkschalter einschalten kann.
Gestern habe ich durch Zufall das Modul RFHEM in der Commandref entdeckt. Eventuell wäre es damit möglich, 2 FHEM-Instanzen auf einem Pi laufen zu lassen und somit die Prozesse mit längerer Laufzeit immer von der zweiten FHEM Instanz verarbeiten zu lassen.

Hat vielleicht schon jeamand damit Erfahrung?

VG, Thomas

[maci]

Mein Pi langweilg sich auch die meiste Zeit.


VG, Thomas

Das ist auch mein Eindruck.
Fhem braucht keine Rechenleistung.
Nur ab und zu, wenn du zB Grafiken erstellst.

Ich habe jedoch gelesen, dass sich die USB Leistung verringert, weil die Ethernetschnittstelle auch auf dem USB Bus sitzt.
Wenn man eine SSD hat und Ethernet nutzt, geht die IO Leistung nach unten.
Das kann dann zum Eindruck der Überforderung führen.
Da kann etwas dran sein, denn ich hatte mich über die Console am rasperry eingelogt und top am laufen.
Als sch dann in Fhem einen Raum mit einigen Grafiken geöffnet hatte, hatte ich den Eindruck dass Fhem hängt, weil einige Zeit nicht gekommen ist.
Doch Top belehrte mich damit, dass zwar fhem etwas mehr Auslastung hat. Also denke ich dass daran etwas wahres liegt.

Im dem Artikel,wo das stand, wird die Empfehlung gegeben, dann über Wlan auf den Rasperry zuzugreifen.
Das muss ich aber erst testen.
Das funktioniert natürlich nur beim RPi 3.
Bei allen anderen bist du auch am USB Bus, da du einen Wlan Stick verwendest.

[ToM_ToM]

Ich habe jedoch gelesen, dass sich die USB Leistung verringert, weil die Ethernetschnittstelle auch auf dem USB Bus sitzt.

Hi maci, deshalb nutze ich keinen Raspberry Pi
Beim BananaPi ist das ein bisschen anders. Der hat auch einen SATA-Port. Undzwar einen echten. Der BananaPi Pro hat zwar auch einen SATA-Port, aber dort gehen die auch über den USB.
Für die Grafiken (SVG-Plots) gibt es ja die Möglichkeit, diese asynchron erzeugen zu lassen damit FHEM nicht blockiert wird.

VG, Thomas

[Bartimaus]

Im dem Artikel,wo das stand, wird die Empfehlung gegeben, dann über Wlan auf den Rasperry zuzugreifen.
Das muss ich aber erst testen.
Das funktioniert natürlich nur beim RPi 3.
Bei allen anderen bist du auch am USB Bus, da du einen Wlan Stick verwendest.

Ja, allerdings kann der Pi3 nicht das schnellere 5GHZ-Wlan, dh. Geschwindigkeitssteigerungen gegenüber LAN erwarte ich nicht, jedoch eine Entlastung des USB.

[Mave]

Weiß jemand, ob das Umstellen des RPI auf "USB Boot" reversibel ist?

[Bartimaus]

Leider kann ich Deine Frage nicht konkret beantworten, aber wozu ist das wichtig ?

Die BootPrio ist
1. SD-Karte
2. USB-Stick/SSD

[Mave]

Ich konnte mittlerweile klären, dass der Vorgang nicht reversibel ist.

Allerdings spielt das in der Tat keine Rolle, weil der RPI von der SD Karte bootet - sofern vorhanden. Wenn nicht, dann bootet er vom USB Device.

[ekur]

@Tom_Tom

Eventuell wäre es damit möglich, 2 FHEM-Instanzen auf einem Pi laufen zu lassen und somit die Prozesse mit längerer Laufzeit immer von der zweiten FHEM Instanz verarbeiten zu lassen.
Hat vielleicht schon jeamand damit Erfahrung?

Hallo,

ich mache das mit FHEM2FHEM schon länger. Ursprünglich hatte ich nur die 1-Wire Abfragen auf eine zweite Instanz gelegt, inzwischen habe ich auch einige Abfragen aus dem Internet bzw Netzwerksachen (NMAP) ausgelagert in eine zweite Instanz.
Gerade beim PI3 mit den vier Kernen ist das kein Problem (im Prinzip langweilt er sich bei mir mehr wie zu arbeiten).

Vorgehen:
Kopiere die fhem.pl in eine zweite Datei mit unterschiedlichem Namen (fhem_xx.pl) erstelle eine eigene cfg Datei, und erstelle für diese Kombination ein Startscript (damit die zweite Instanz auch beim Reboot automatisch gestartet wird). Dann die zweite Instanz per FHEM2FHEM einbinden, fertig.

Interessant ist das für alles das a) Zeit braucht (blocking) oder b) wenn Du nur bestimmte Werte brauchst, aber eine ganze Menge abgefragt wird. Ich mache z.B. eine Abfrage auf WU auf eine Wetterstation in der Nachbarschaft, von der brauche ich aber nur einen Wert, den übergebe ich dann per clonedummy an meine Steuerungsinstanz.

[ToM_ToM]

Kopiere die fhem.pl in eine zweite Datei mit unterschiedlichem Namen (fhem_xx.pl) erstelle eine eigene cfg Datei, und erstelle für diese Kombination ein Startscript (damit die zweite Instanz auch beim Reboot automatisch gestartet wird). Dann die zweite Instanz per FHEM2FHEM einbinden, fertig.

Hey ekur, vielen Dank für die Kurzanleitung. Hast du dir mal das RFHEM Modul angesehen? Das klingt für mich auf dem ersten Blick noch etwas interessanter. Getestet habe ich jedoch noch keines von beiden.

[ekur]

Ich habe das über FHEM2FHEM gelöst da ich nur in die eine Richtung gehe (Datensammler zu Steuerung) und da das RFHEM nicht offiziell supported wird.

[Wernieman]

Wegen Zuverlässigkeit von SSD:
Beim Pi geht eben (fast) alles über den USB-Bus, auch die Sata-Schnitstelle. Wenn also auf USB-Ebene ein Problem ist, ist bei SSD eben auch diese Weg. Linux (Unix) mag es nicht, wenn das Dateisystem weg ist .... und über die Stabilität von USB beim Pi kann man sich in den passenden Foren "schlau" machen ...

[LuckyDay]

Code Auswählen Erweitern

pi@raspberrypi ~ $ uptime
22:28:23 up 117 days, 57 min,  1 user,  load average: 0.08, 0.03, 0.05
pi@raspberrypi ~ $ df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/root       230G  3.2G  215G   2% /
devtmpfs        214M     0  214M   0% /dev
tmpfs            44M  240K   44M   1% /run
tmpfs           5.0M     0  5.0M   0% /run/lock
tmpfs            87M     0   87M   0% /run/shm
/dev/mmcblk0p1   56M   20M   37M  36% /boot
/dev/root       230G  3.2G  215G   2% /var/log.hdd
ramlog-tmpfs    218M  1.2M  217M   1% /var/log
pi@raspberrypi ~ $


@ Wernieman , dafür funktioniert es sehr gut (bei mir)

[Gunther]

So, kurzer Status.

Ich bin fast durch mit dem Umzug auf einen Intel Nuc 7. Version mit I3.

Habe Proxmox als Virtualisierungsumgebung und darauf in einem Container auf Ubuntu 16.04 FHEM laufen.

Meine beiden FTDI232 Sticks habe ich zwar an den Container weiterleiten können aber nicht in FHEM einbinden können. Den Jeelink habe ich über ser2net auf einem RPI1 der eh lief (Razberry) zum Laufen bekommen. Mein Optolink Adapter für meine Viessmann Heizung versuche ich die Tage ebenfalls per ser2net einzubinden.

Die Backups sind nun sehr einfach, ebenfalls kurz ausschalten oder eine Kopie machen um mal was zu testen. Alles vom Sofa aus. Stark!
Und zum Speed: Der Hammer! Ich bin happy. Meine Freezes sind (gefühlt) weg, allerdings kann ich perfmon nicht nutzen, da FHEM dann nicht mehr läuft, warum auch immer.

Ich beobachte und berichte. Für mich war das ein wichtiger Schritt.

[Gunther]

Als nächstes werde ich mir einen Container mit mysql einrichten und eine FHEM Kopie zum Testen von DBLOG.