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?
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?
Zitat(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.
also wird was schnelleres als der RPI nicht so einfach?
Ich bin noch auf Jessi. Englisch kein Problem.
Zitat von: Gunther am 03 Januar 2018, 22:27:52
also wird was schnelleres als der RPI nicht so einfach?
Ich bin noch auf Jessi. Englisch kein Problem.
das widerspricht sich zu dem-->
Zitatmöglichst energiesparenden Alternativen
schau dich bei NUC 's z-box usw um
https://forum.fhem.de/index.php/topic,77356.0.html (https://forum.fhem.de/index.php/topic,77356.0.html)
Dann schau dir doch mal die Hardware von dieser Seite an
https://wiki.fhem.de/wiki/ODROID_XU4 (https://wiki.fhem.de/wiki/ODROID_XU4)
Schnitzelbrain
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.
Wo finde ich die Anzahl der Definitionen?
Bei mir laufen bestimmt einige inperformant aufgesetzte DOIFs und notifying 😂
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.
Zitat von: Gunther am 04 Januar 2018, 07:37:38
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
Stimmt. Geht ja auch seit ein paar Monaten
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.
FHEM ist singlethreaded. d.h. wenn deine doifs/notifys inperformant (sleeps ahoi) sind, wirst sich selbst auf einem supercomputer keine performanceverbesserung ergeben.
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
Würde auch eher erst mal nach Performance-Killern suchen, Stichworte: apptime und perfmon.
Zitat von: blecher-at am 04 Januar 2018, 14:11:11
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.
Ob ich eine große Installation habe, kann ich nicht beurteilen. Da kommt eine Menge zusammen.
Server started with 1110 defined entities
fheminfo:
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? :o
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
Die possible freeze sind nicht gut. Das sind ganz schön viele nacheinander. Das solltest Du Dir mal genauer anschauen.
(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
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...
Mich würde Mal der Eventmonitor interessieren. Das muss ja nur so durch rattern.
Hier mal ein Auszug aus apptime:
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...
ZitatJa, 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 ...
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.
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.
habt Ihr Vergleichswerte von I3 und I5 Systemen bzgl. Stromverbrauch?
habe hier etwas gefunden:
https://www.notebookcheck.com/Test-Intel-NUC5i3RYK-Mini-PC-Broadwell-Core-i3-5010U.147828.0.html (https://www.notebookcheck.com/Test-Intel-NUC5i3RYK-Mini-PC-Broadwell-Core-i3-5010U.147828.0.html)
ZitatDie 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.
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.
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.
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.
Ich habe zu viele Logs. Die recht wenigen Plots hängen in einem eigenen Raum.
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...
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?
Zitat von: Gunther am 07 Januar 2018, 10:57:32
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...
danke.
Habe hier mal ein Thema aufgemacht für mein Dilemma:
https://forum.fhem.de/index.php?topic=82276.0 (https://forum.fhem.de/index.php?topic=82276.0)
Zitat von: maci am 06 Januar 2018, 22:46:18
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.
Zitat von: Mave am 08 Januar 2018, 10:59:03
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.
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?
Zitat von: Mave am 08 Januar 2018, 12:29:01
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.
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.
sudo resize2fs -p /dev/gerätename 10G # Vergrößert bzw. Verkleinert das Dateisystem auf 10 Gigabyte Gesamtgröße....
darf allerdings nicht gemountet sein.
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
Zitat von: ToM_ToM am 08 Januar 2018, 12:59:31
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.
ZitatIch 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
Zitat von: maci am 08 Januar 2018, 13:37:18
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.
Weiß jemand, ob das Umstellen des RPI auf "USB Boot" reversibel ist?
Leider kann ich Deine Frage nicht konkret beantworten, aber wozu ist das wichtig ?
Die BootPrio ist
1. SD-Karte
2. USB-Stick/SSD
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.
@Tom_Tom
Zitat von: ToM_ToM am 08 Januar 2018, 12:59:31
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.
ZitatKopiere 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.
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.
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 ...
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)
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.
Als nächstes werde ich mir einen Container mit mysql einrichten und eine FHEM Kopie zum Testen von DBLOG.