Seite 17 von 19

Re: RaspberryMatic 3.45.7.20190504 – Erfahrungsberichte

Verfasst: 08.05.2019, 16:20
von Jailbraik
VIELEN DANK - Feuerabend gerettet.

:)
:D

Re: RaspberryMatic 3.45.7.20190504 – Erfahrungsberichte

Verfasst: 08.05.2019, 16:30
von Catzjes
Catzjes hat geschrieben:
06.05.2019, 08:02
Guten Morgen,

Nach dem Update bekomme ich jede 18 Sekunden eine Fehler im CUxD Full Syslog.

Code: Alles auswählen

May  6 07:58:34 homematic-raspi user.err monit[1100]: 'voltageCheck' status failed (0) -- no output
May  6 07:58:52 homematic-raspi user.err monit[1100]: 'voltageCheck' status failed (0) -- no output
May  6 07:59:10 homematic-raspi user.err monit[1100]: 'voltageCheck' status failed (0) -- no output
May  6 07:59:28 homematic-raspi user.err monit[1100]: 'voltageCheck' status failed (0) -- no output
jmaus hat geschrieben:
07.05.2019, 21:24


Da wäre natürlich die Frage um welchen RaspberryPi es sich hier bitte genau handelt? Bitte die Information nachliefern.

Und dann bitte mal folgende Befehle ausführen und die Ausgaben präsentieren:

Code: Alles auswählen

monit status voltageCheck

Code: Alles auswählen

/usr/bin/vcgencmd get_throttled

Guten Tag,

In meinem Fall geht es um einen Pi 3B+.

Code: Alles auswählen

# monit status voltageCheck
Monit 5.25.2 uptime: 2d 6h 26m

Program 'voltageCheck'
  status                       Status failed
  monitoring status            Monitored
  monitoring mode              active
  on reboot                    start
  last exit value              0
  last output                  -
  data collected               Wed, 08 May 2019 16:13:55

# 

# /usr/bin/vcgencmd get_throttled
throttled=0x50000
# 

Re: RaspberryMatic 3.45.7.20190504 – Erfahrungsberichte

Verfasst: 08.05.2019, 17:00
von FreshHomeUser
jmaus hat geschrieben:
08.05.2019, 08:03
AndiN hat geschrieben:
08.05.2019, 07:39
Außerdem steht ein paar Seiten vorher noch wie man den Upload prüfen kann. Hast Du das auch schon versucht/beobachtet?
Den Aufwand würde ich im ersten Ansatz nicht treiben, sondern erst einmal probieren das Update über das RecoverySystem einzuspielen. Erst wenn es damit auch nicht klappt könnte man das so näher debuggen...
Im RecoverySystem ging es fehlerfrei. Danke für den Tip !

Re: RaspberryMatic 3.45.7.20190504 – Erfahrungsberichte

Verfasst: 08.05.2019, 17:11
von jmaus
Catzjes hat geschrieben:
08.05.2019, 16:30
In meinem Fall geht es um einen Pi 3B+.

Code: Alles auswählen

# /usr/bin/vcgencmd get_throttled
throttled=0x50000
Ok, das klärt es.

Die Ausgabe deutet in der Tat daraufhin das monit bzw der WatchDog hier recht hat und dein RaspberryPi hier eine Unterspannung gemeldet hat während seiner laufzeit. Es wäre also zu klären was du da für ein Netzteil dran betreibst und welche externen Geräte du da angeschlossen hast die ggf. zuviel Strom ziehen könnten.

In jeden Falle solltest du die Meldung jedoch ernst nehmen und herausfinden warum der Pi eine Unterspannung meldet.

Re: RaspberryMatic 3.45.7.20190504 – Erfahrungsberichte

Verfasst: 08.05.2019, 17:25
von Catzjes
jmaus hat geschrieben:
08.05.2019, 17:11
Catzjes hat geschrieben:
08.05.2019, 16:30
In meinem Fall geht es um einen Pi 3B+.

Code: Alles auswählen

# /usr/bin/vcgencmd get_throttled
throttled=0x50000
Ok, das klärt es.

Die Ausgabe deutet in der Tat daraufhin das monit bzw der WatchDog hier recht hat und dein RaspberryPi hier eine Unterspannung gemeldet hat während seiner laufzeit. Es wäre also zu klären was du da für ein Netzteil dran betreibst und welche externen Geräte du da angeschlossen hast die ggf. zuviel Strom ziehen könnten.

In jeden Falle solltest du die Meldung jedoch ernst nehmen und herausfinden warum der Pi eine Unterspannung meldet.
OK vielen Dank. Netzteil ist 2A und auf USB ist ein RFLink angeschlossen. Ich werde testen ohne RFLink und mit einem anderen Netzteil.

Re: RaspberryMatic 3.45.7.20190504 – Erfahrungsberichte

Verfasst: 08.05.2019, 17:27
von LibertyX
2A ist für einen 3B+ zu wenig mindestens 2,5A optimal wären 3A

Re: RaspberryMatic 3.45.7.20190504 – Erfahrungsberichte

Verfasst: 09.05.2019, 00:07
von MathiasZ
onkeltommy hat geschrieben:
08.05.2019, 09:24
Hi
und beim Tinker dann mal schnell die eMMC umlöten ?
Woher bekommt man die originale Firmware der CCU3?
Dann bräuchte man da auch eine 2. SD-Karte, wobei ich behaupten will, dass es eine SD-Karte mit der originalen FW nicht zu kaufen gibt.
Daß man die einfach als Backup auf eine andere SD-Karte überspielen kann, möchte ich jetzt an dieser Stelle auch mal bezweifeln.

Re: RaspberryMatic 3.45.7.20190504 – Erfahrungsberichte

Verfasst: 09.05.2019, 07:53
von darkbrain85
Woher bekommt man die originale Firmware der CCU3?
Von EQ3?
Notfalls eine Karte mit Raspberrymatic flashen, Recovery starten und dann die EQ3 Firmware einspielen. Das sollte doch problemlos gehen!

Dann bräuchte man da auch eine 2. SD-Karte, wobei ich behaupten will, dass es eine SD-Karte mit der originalen FW nicht zu kaufen gibt.
Daß man die einfach als Backup auf eine andere SD-Karte überspielen kann, möchte ich jetzt an dieser Stelle auch mal bezweifeln.
Warum das? Eine SD Karte zu kopieren ist ja wirklich kein Hexenwerk...

Re: RaspberryMatic 3.45.7.20190504 – Erfahrungsberichte

Verfasst: 09.05.2019, 09:38
von klana
Guten Morgen,

im HMServer.log gibt es eine Exception - wichtig oder vergessen?

Code: Alles auswählen

May 7 11:12:42 de.eq3.ccu.server.BaseHMServer INFO  [Thread-1] Create GroupDeviceHandler 
May 7 11:12:42 de.eq3.ccu.groupdevice.service.GroupDeviceHandler INFO  [Thread-1] @GroupDeviceHandler - initializing... 
May 7 11:12:42 de.eq3.ccu.groupdevice.service.GroupDeviceHandler INFO  [Thread-1] --> created groupDeviceDispatcher (GroupDeviceService to BidCoS (via Dispatcher)) 
May 7 11:12:42 de.eq3.ccu.groupdevice.service.GroupDeviceHandler INFO  [Thread-1] --> created virtualDeviceHandler (GroupDeviceService to ReGa) 
May 7 11:12:42 de.eq3.ccu.groupdevice.service.GroupDeviceHandler INFO  [Thread-1] --> got groupDefinitionProvider 
May 7 11:12:42 de.eq3.ccu.server.BaseHMServer INFO  [Thread-1] Create BidCosGroupMemberProvider 
May 7 11:12:42 de.eq3.ccu.server.BaseHMServer INFO  [Thread-1] Init groupAdministrationService 
May 7 11:12:42 de.eq3.ccu.server.BaseHMServer INFO  [Thread-1] Init Virtual OS Device 
May 7 11:12:42 de.eq3.ccu.server.BaseHMServer INFO  [Thread-1] Init ESHLight Bridge 
May 7 11:12:43 de.eq3.ccu.server.BaseHMServer INFO  [Thread-1] Create RrdDatalogging 
May 7 11:12:43 de.eq3.ccu.server.BaseHMServer INFO  [Thread-1] Create MeasurementService 
May 7 11:12:43 de.eq3.ccu.server.BaseHMServer INFO  [Thread-1] Init MeasurementService 
May 7 11:12:43 de.eq3.ccu.server.BaseHMServer INFO  [Thread-1] Create HTTP Server 
May 7 11:12:43 de.eq3.ccu.server.BaseHMServer INFO  [Thread-1] Create BidCos context and start handler 
May 7 11:12:43 de.eq3.ccu.server.BaseHMServer INFO  [Thread-1] Create group context and start handler 
May 7 11:12:43 de.eq3.cbcs.legacy.bidcos.rpc.LegacyServiceHandler INFO  [vert.x-worker-thread-0] (un)registerCallback on LegacyServiceHandler called from url: http://127.0.0.1:39292/bidcos 
May 7 11:12:43 de.eq3.cbcs.legacy.bidcos.rpc.LegacyServiceHandler INFO  [vert.x-worker-thread-0] init finished 
May 7 11:12:43 de.eq3.cbcs.legacy.bidcos.rpc.internal.InterfaceInitializer INFO  [vert.x-worker-thread-0] Added InterfaceId: HmIP-RF_java 
May 7 11:12:43 de.eq3.cbcs.legacy.bidcos.rpc.internal.DeviceUtil INFO  [vert.x-worker-thread-0] updateDevicesForClient HmIP-RF_java -> 52 device addresses will be added 
May 7 11:12:44 de.eq3.ccu.server.BaseHMServer INFO  [Thread-1] Starting HMServer done 
[color=#FF0000]May 7 11:12:45 de.eq3.ccu.bidcos.dispatcher.BidCosRpcDispatcher ERROR [vert.x-eventloop-thread-4] event: Error for listener [email protected]: 
java.lang.NullPointerException
	at de.eq3.ccu.virtualdevice.service.internal.bidcos.aggregation.LastBidCosValueAggregator.aggregate(LastBidCosValueAggregator.java:24)
	at de.eq3.ccu.groupdevice.service.BidCosDeviceEventHandler.event(BidCosDeviceEventHandler.java:154)
	at de.eq3.ccu.bidcos.dispatcher.BidCosRpcDispatcher.event(BidCosRpcDispatcher.java:214)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:498)
	at de.eq3.cbcs.legacy.communication.rpc.internal.rpc.AnnotationAwareRpcHandler.execute(AnnotationAwareRpcHandler.java:80)
	at de.eq3.cbcs.legacy.communication.rpc.internal.rpc.AnnotationAwareRpcHandler.multiCall(AnnotationAwareRpcHandler.java:128)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:498)
	at de.eq3.cbcs.legacy.communication.rpc.internal.rpc.AnnotationAwareRpcHandler.execute(AnnotationAwareRpcHandler.java:80)
	at de.eq3.ccu.server.internal.RpcMessageHandler.handle(RpcMessageHandler.java:70)
	at de.eq3.ccu.server.internal.RpcMessageHandler.handle(RpcMessageHandler.java:24)
	at io.vertx.core.eventbus.impl.HandlerRegistration.deliver(HandlerRegistration.java:212)
	at io.vertx.core.eventbus.impl.HandlerRegistration.handle(HandlerRegistration.java:191)
	at io.vertx.core.eventbus.impl.EventBusImpl.lambda$deliverToHandler$3(EventBusImpl.java:505)
	at io.vertx.core.impl.ContextImpl.lambda$wrapTask$2(ContextImpl.java:337)
	at io.netty.util.concurrent.AbstractEventExecutor.safeExecute(AbstractEventExecutor.java:163)
	at io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:403)
	at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:445)
	at io.netty.util.concurrent.SingleThreadEventExecutor$5.run(SingleThreadEventExecutor.java:858)
	at java.lang.Thread.run(Thread.java:748)[/color]
May 7 11:12:58 de.eq3.ccu.virtualdevice.service.internal.rega.VirtualDeviceHandlerRega INFO  [vert.x-eventloop-thread-5] (un)registerCallback on VirtualDeviceHandlerRega called from url: xmlrpc_bin://127.0.0.1:31999 
May 7 11:12:58 de.eq3.ccu.virtualdevice.service.internal.rega.VirtualDeviceHandlerRega INFO  [vert.x-eventloop-thread-5] Added InterfaceId: 1008 
May 7 11:12:58 de.eq3.ccu.virtualdevice.service.internal.rega.BackendWorker INFO  [vert.x-worker-thread-13] Execute BackendCommand: de.eq3.ccu.virtualdevice.service.internal.rega.BackendUpdateDevicesCommand 
May 7 11:12:58 de.eq3.ccu.virtualdevice.service.internal.rega.BackendUpdateDevicesCommand INFO  [vert.x-worker-thread-13] updateDevicesForClient -> 36 device addresses will be added 
May 7 11:13:08 de.eq3.cbcs.legacy.bidcos.rpc.LegacyServiceHandler INFO  [vert.x-worker-thread-0] (un)registerCallback on LegacyServiceHandler called from url: xmlrpc_bin://127.0.0.1:31999 
May 7 11:13:08 de.eq3.cbcs.legacy.bidcos.rpc.LegacyServiceHandler INFO  [vert.x-worker-thread-0] init finished 
May 7 11:13:08 de.eq3.cbcs.legacy.bidcos.rpc.internal.InterfaceInitializer INFO  [vert.x-worker-thread-2] Added InterfaceId: 1009 
May 7 11:13:09 de.eq3.ccu.virtualdevice.service.internal.rega.BackendUpdateDevicesCommand INFO  [vert.x-worker-thread-13] set ready config of INT0000001 
May 7 11:13:09 de.eq3.ccu.virtualdevice.service.internal.rega.BackendUpdateDevicesCommand INFO  [vert.x-worker-thread-13] set ready config of INT0000002 

Re: RaspberryMatic 3.45.7.20190504 – Erfahrungsberichte

Verfasst: 09.05.2019, 10:19
von krk-elektrotechnik
Hi Jens,

ist vielleicht etwas OT meine Frage, aber ich hoffe Du beantwortest sie mir trotzdem ;)

Ich möchte eine entfernte RM via OpenVPN oder Cloudmatic updaten. Leider ist mir dies bisher nicht gelungen.
Weiter als die Meldung im FF, das die Datei übertragen wird, bin ich nie gekommen.
Ist es möglich das Update-File per SCP zu übertragen und das Update dann über die Konsole zu starten ?
Wenn ja, in welches Verzeichnis kopiere ich das File und wie lauter der Befehl um das Update zu starten ?
Vielen Dank schon mal.
Grüße
Benjamin