Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

HMIPServer is constantly restarted #613

Closed
koegel opened this issue Apr 28, 2019 · 25 comments

Comments

Projects
None yet
4 participants
@koegel
Copy link

commented Apr 28, 2019

Describe the bug
HMIPServer is constantly restarted . The alarm messages show that the HMIPServer is restarted about once every minute. None of the HomematicIP devices can be controlled via the central since they do not show in the WebUI any more.
In the hmserver.log an exception is logged during restart of the HMIPServer (full log see at the bottom):

Apr 28 11:28:44 de.eq3.cbcs.legacy.bidcos.rpc.LegacyServiceHandler ERROR [vert.x-worker-thread-4] Unable to fetch information for initialization of VirtualRemoteControl 
java.lang.NullPointerException
	at de.eq3.cbcs.legacy.bidcos.rpc.internal.VirtualRemoteControl.updateLinkCache(VirtualRemoteControl.java:793)
	at de.eq3.cbcs.legacy.bidcos.rpc.internal.VirtualRemoteControl.updateLinkCache(VirtualRemoteControl.java:784)
	at de.eq3.cbcs.legacy.bidcos.rpc.internal.VirtualRemoteControl.<init>(VirtualRemoteControl.java:135)
	at de.eq3.cbcs.legacy.bidcos.rpc.LegacyServiceHandler.<init>(LegacyServiceHandler.java:110)
	at de.eq3.cbcs.legacy.bidcos.rpc.internal.LegacyAPIWorker.start(LegacyAPIWorker.java:68)
	at io.vertx.core.AbstractVerticle.start(AbstractVerticle.java:111)
	at io.vertx.core.impl.DeploymentManager.lambda$doDeploy$8(DeploymentManager.java:434)
	at io.vertx.core.impl.ContextImpl.lambda$wrapTask$2(ContextImpl.java:337)
	at io.vertx.core.impl.TaskQueue.lambda$new$0(TaskQueue.java:60)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
	at java.lang.Thread.run(Thread.java:748)

To Reproduce
I do not know how to reproduce this. On my system the problem seems permanent since yesterday. Restarting the raspberry-pi does not change anything.

Expected behavior
HMIPServer should not restart constantly and Homematic IP devices can be controlled via the central.

System information (please complete the following information):

  • Version 3.45.5.20190330
  • Hardware: RaspberryPi3

Additional context
Log output of hmserver.log:

> Apr 28 11:28:45 de.eq3.cbcs.lib.remotecommadapter.AccessPointCommDevice INFO  [vert.x-eventloop-thread-2] SYSTEM: connector open 
> Apr 28 11:28:45 de.eq3.cbcs.server.core.otau.DeviceBackgroundUpdateSubsystem INFO  [vert.x-eventloop-thread-2] SYSTEM: Checking all devices on all accesspoints for updates 
> Apr 28 11:28:45 de.eq3.cbcs.server.core.otau.DeviceBackgroundUpdateSubsystem INFO  [vert.x-eventloop-thread-2] SYSTEM: There are 1 APs queued with updatable devices (RF) 
> Apr 28 11:28:45 de.eq3.cbcs.server.core.otau.DeviceBackgroundUpdateSubsystem INFO  [vert.x-eventloop-thread-2] SYSTEM: There are 0 APs queued with updatable devices (WIRED) 
> Apr 28 11:28:46 de.eq3.cbcs.vertx.management.VertxManager INFO  [vert.x-eventloop-thread-6] SYSTEM: start of LegacyInitializion succeeded (cef2f07d-a6e0-419f-aeb9-aa456588dc28) 
> Apr 28 11:28:46 de.eq3.cbcs.vertx.management.VertxManager INFO  [Thread-0] SYSTEM: initial deployment complete _____________________________________________________ 
> Apr 28 11:28:46 de.eq3.cbcs.server.local.LocalServer INFO  [Thread-0] SYSTEM: Bind XML-RPC api to port 32010 
> Apr 28 11:28:51 de.eq3.ccu.server.BaseHMServer INFO  [Thread-1] Default MaxEventLoopExecuteTime: 2000000000 
> Apr 28 11:28:51 de.eq3.ccu.server.BaseHMServer INFO  [Thread-1] Default BlockedThreadCheckInterval: 1000 
> Apr 28 11:28:51 de.eq3.ccu.server.BaseHMServer INFO  [Thread-1] Default MaxWorkerExecuteTime: 60000000000 
> Apr 28 11:28:51 de.eq3.ccu.server.BaseHMServer INFO  [Thread-1] Default EventLoopPoolSize: 8 
> Apr 28 11:28:51 de.eq3.cbcs.vertx.management.VertxManager INFO  [Thread-1] SYSTEM: added for deployment [BackendWorker] (1) *worker 
> Apr 28 11:28:51 de.eq3.cbcs.vertx.management.VertxManager INFO  [Thread-1] SYSTEM: added for deployment [GroupRequestWorker] (1) *worker 
> Apr 28 11:28:51 de.eq3.cbcs.vertx.management.VertxManager INFO  [Thread-1] SYSTEM: added for deployment [DiagramRequestWorker] (1) *worker 
> Apr 28 11:28:51 de.eq3.cbcs.vertx.management.VertxManager INFO  [Thread-1] SYSTEM: added for deployment [StorageRequestWorker] (1) *worker 
> Apr 28 11:28:51 de.eq3.cbcs.vertx.management.VertxManager INFO  [Thread-1] SYSTEM: added for deployment [DeviceFirmwareRequestWorker] (1) *worker 
> Apr 28 11:28:51 de.eq3.cbcs.vertx.management.VertxManager INFO  [Thread-1] SYSTEM: added for deployment [EnergyPriceRequestWorker] (1) *worker 
> Apr 28 11:28:51 de.eq3.cbcs.vertx.management.VertxManager INFO  [Thread-1] SYSTEM: added for deployment [CouplingRequestWorker] (1) *worker 
> Apr 28 11:28:51 de.eq3.cbcs.vertx.management.VertxManager INFO  [Thread-1] SYSTEM: added for deployment [RegaClientWorker] (1) *worker 
> Apr 28 11:28:51 de.eq3.cbcs.vertx.management.VertxManager INFO  [Thread-1] SYSTEM: added for deployment [GroupConfigurationPersistenceFileSystem] (1) *worker 
> Apr 28 11:28:51 de.eq3.cbcs.vertx.management.VertxManager INFO  [Thread-1] SYSTEM: added for deployment [HmIPGatewayManagementRequestWorker] (1) *worker 
> Apr 28 11:28:51 de.eq3.cbcs.vertx.management.VertxManager INFO  [Thread-1] SYSTEM: deploying 10 classes to Vert.x 
> Apr 28 11:28:51 de.eq3.cbcs.vertx.management.VertxManager INFO  [Thread-1] SYSTEM: 10 VertxDeployers initialized 
> Apr 28 11:28:51 de.eq3.cbcs.vertx.management.VertxManager INFO  [vert.x-eventloop-thread-5] SYSTEM: start of BackendWorker succeeded (4610a042-b61c-4ca2-88df-0503a7abd3ac) 
> Apr 28 11:28:51 de.eq3.cbcs.vertx.management.VertxManager INFO  [vert.x-eventloop-thread-2] SYSTEM: start of GroupConfigurationPersistenceFileSystem succeeded (a869be18-b217-449e-917e-a89e4e209674) 
> Apr 28 11:28:51 de.eq3.cbcs.vertx.management.VertxManager INFO  [vert.x-eventloop-thread-5] SYSTEM: start of EnergyPriceRequestWorker succeeded (5fbd06b9-dce4-4595-ae78-882d54f96f45) 
> Apr 28 11:28:51 de.eq3.cbcs.vertx.management.VertxManager INFO  [vert.x-eventloop-thread-2] SYSTEM: start of CouplingRequestWorker succeeded (459c5efb-56ac-4c77-8fde-8ebcbfa68995) 
> Apr 28 11:28:51 de.eq3.cbcs.vertx.management.VertxManager INFO  [vert.x-eventloop-thread-2] SYSTEM: start of RegaClientWorker succeeded (f9fa9673-e8a5-49f3-b5e3-5049ba33e0ee) 
> Apr 28 11:28:51 de.eq3.cbcs.vertx.management.VertxManager INFO  [vert.x-eventloop-thread-1] SYSTEM: start of StorageRequestWorker succeeded (8be5f4dc-b986-4aef-b9fa-1d4a4666ddfc) 
> Apr 28 11:28:51 de.eq3.cbcs.vertx.management.VertxManager INFO  [vert.x-eventloop-thread-1] SYSTEM: start of GroupRequestWorker succeeded (a3453624-7550-4d95-84ac-8ba8b4fcfb3c) 
> Apr 28 11:28:51 de.eq3.cbcs.vertx.management.VertxManager INFO  [vert.x-eventloop-thread-5] SYSTEM: start of DiagramRequestWorker succeeded (95c2acb0-09a7-4b35-8626-ffa3068c109c) 
> Apr 28 11:28:51 de.eq3.cbcs.vertx.management.VertxManager INFO  [vert.x-eventloop-thread-1] SYSTEM: start of DeviceFirmwareRequestWorker succeeded (e53c4fcb-e7b5-4750-9e99-72449127bb38) 
> Apr 28 11:28:51 de.eq3.cbcs.vertx.management.VertxManager INFO  [vert.x-eventloop-thread-5] SYSTEM: start of HmIPGatewayManagementRequestWorker succeeded (c76bf488-f86a-495d-9170-e6a48374d1ed) 
> Apr 28 11:28:51 de.eq3.cbcs.vertx.management.VertxManager INFO  [Thread-1] SYSTEM: initial deployment complete _____________________________________________________ 
> Apr 28 11:28:51 de.eq3.ccu.server.BaseHMServer INFO  [Thread-1] Starting HMServer at 127.0.0.1:39292 
> Apr 28 11:28:51 de.eq3.ccu.server.BaseHMServer INFO  [Thread-1] Read Configuration 
> Apr 28 11:28:51 de.eq3.ccu.server.BaseHMServer INFO  [Thread-1] Create Bidcos Dispatcher 
> Apr 28 11:28:51 de.eq3.ccu.server.BaseHMServer INFO  [Thread-1] InitBidCosCache 
> Apr 28 11:28:57 de.eq3.cbcs.server.core.otau.DeviceBackgroundUpdateSubsystem INFO  [vert.x-eventloop-thread-2] AP 3014F711A061A7D70992B8D0: OTAU Handler 447cca82-c488-42eb-b081-b2258ca8a839 continues for device(s) [3014F711A0001118A994F0E9] 
> Apr 28 11:29:13 de.eq3.lib.util.dynamics.GenericFactory INFO  [main] @GenericFactory 
> Apr 28 11:29:13 de.eq3.lib.util.dynamics.GenericFactory INFO  [main] created instance of HMServerConfiguration with parameter(s) 
> Apr 28 11:29:13 de.eq3.lib.util.dynamics.GenericFactory INFO  [main] passed 1 parameter(s), in declarative order [String] 
> Apr 28 11:29:19 de.eq3.cbcs.vertx.management.VertxManager INFO  [Thread-0] SYSTEM: added for deployment [HMIPTRXWriterWorker] (1) *worker 
> Apr 28 11:29:19 de.eq3.cbcs.vertx.management.VertxManager INFO  [Thread-0] SYSTEM: added for deployment [KeyServerWorker] (1) *worker 
> Apr 28 11:29:19 de.eq3.cbcs.vertx.management.VertxManager INFO  [Thread-0] SYSTEM: added for deployment [KryoPersistenceWorker] (1) *worker 
> Apr 28 11:29:19 de.eq3.cbcs.vertx.management.VertxManager INFO  [Thread-0] SYSTEM: added for deployment [TransactionSubsystemHandler] (1) *worker 
> Apr 28 11:29:19 de.eq3.cbcs.vertx.management.VertxManager INFO  [Thread-0] SYSTEM: added for deployment [FirmwareLoaderFileSystem] (1) *worker 
> Apr 28 11:29:19 de.eq3.cbcs.vertx.management.VertxManager INFO  [Thread-0] SYSTEM: added for deployment [LocalServerPersistentDataLoader] (1)  
> Apr 28 11:29:19 de.eq3.cbcs.vertx.management.VertxManager INFO  [Thread-0] SYSTEM: added for deployment [LocalServerAdapterInitialization] (1)  
> Apr 28 11:29:19 de.eq3.cbcs.vertx.management.VertxManager INFO  [Thread-0] SYSTEM: added for deployment [BackendCommandHandler] (1)  
> Apr 28 11:29:19 de.eq3.cbcs.vertx.management.VertxManager INFO  [Thread-0] SYSTEM: added for deployment [DeviceInclusionAcceptHandler] (1)  
> Apr 28 11:29:19 de.eq3.cbcs.vertx.management.VertxManager INFO  [Thread-0] SYSTEM: added for deployment [CheckDeviceExistHandler] (1)  
> Apr 28 11:29:19 de.eq3.cbcs.vertx.management.VertxManager INFO  [Thread-0] SYSTEM: added for deployment [IncomingHMIPFrameHandler] (1)  
> Apr 28 11:29:19 de.eq3.cbcs.vertx.management.VertxManager INFO  [Thread-0] SYSTEM: added for deployment [DeviceBackgroundUpdateSubsystem] (1)  
> Apr 28 11:29:19 de.eq3.cbcs.vertx.management.VertxManager INFO  [Thread-0] SYSTEM: added for deployment [DeviceLiveUpdateSubsystem] (1)  
> Apr 28 11:29:19 de.eq3.cbcs.vertx.management.VertxManager INFO  [Thread-0] SYSTEM: added for deployment [DeviceInclusionDefaultConfigurationChanger] (1)  
> Apr 28 11:29:19 de.eq3.cbcs.vertx.management.VertxManager INFO  [Thread-0] SYSTEM: added for deployment [CyclicSmokeDetectorAwakening] (1)  
> Apr 28 11:29:19 de.eq3.cbcs.vertx.management.VertxManager INFO  [Thread-0] SYSTEM: added for deployment [AccessPointElectroCardioGram] (1)  
> Apr 28 11:29:19 de.eq3.cbcs.vertx.management.VertxManager INFO  [Thread-0] SYSTEM: added for deployment [LocalServerFirmwareUpdateInitialization] (1)  
> Apr 28 11:29:19 de.eq3.cbcs.vertx.management.VertxManager INFO  [Thread-0] SYSTEM: added for deployment [AccessPointAuthorisationHandler] (1)  
> Apr 28 11:29:19 de.eq3.cbcs.vertx.management.VertxManager INFO  [Thread-0] SYSTEM: added for deployment [AccessPointMessageDispatcher] (1)  
> Apr 28 11:29:19 de.eq3.cbcs.vertx.management.VertxManager INFO  [Thread-0] SYSTEM: added for deployment [AccessPointWatchdog] (1)  
> Apr 28 11:29:19 de.eq3.cbcs.vertx.management.VertxManager INFO  [Thread-0] SYSTEM: added for deployment [WebSocketManager] (1)  
> Apr 28 11:29:19 de.eq3.cbcs.vertx.management.VertxManager INFO  [Thread-0] SYSTEM: added for deployment [AccessPointCommDevice] (1)  
> Apr 28 11:29:19 de.eq3.cbcs.vertx.management.VertxManager INFO  [Thread-0] SYSTEM: added for deployment [RouterKeyServerWorker] (1) *worker 
> Apr 28 11:29:19 de.eq3.cbcs.vertx.management.VertxManager INFO  [Thread-0] SYSTEM: added for deployment [AccessPointKeyServerWorker] (1) *worker 
> Apr 28 11:29:19 de.eq3.cbcs.vertx.management.VertxManager INFO  [Thread-0] SYSTEM: added for deployment [RemoteCommAdapterInitialization] (1)  
> Apr 28 11:29:19 de.eq3.cbcs.vertx.management.VertxManager INFO  [Thread-0] SYSTEM: added for deployment [RemoteCommAdapterFinalization] (1)  
> Apr 28 11:29:19 de.eq3.cbcs.vertx.management.VertxManager INFO  [Thread-0] SYSTEM: added for deployment [LanRoutingWorker] (1) *worker 
> Apr 28 11:29:19 de.eq3.cbcs.vertx.management.VertxManager INFO  [Thread-0] SYSTEM: added for deployment [LegacyNotificationHandler] (1) *worker 
> Apr 28 11:29:19 de.eq3.cbcs.vertx.management.VertxManager INFO  [Thread-0] SYSTEM: added for deployment [LegacyAPIWorker] (1) *worker 
> Apr 28 11:29:19 de.eq3.cbcs.vertx.management.VertxManager INFO  [Thread-0] SYSTEM: added for deployment [LegacyBackendNotificationHandler] (3) *worker 
> Apr 28 11:29:19 de.eq3.cbcs.vertx.management.VertxManager INFO  [Thread-0] SYSTEM: added for deployment [LegacyBlindLevelCorrectionHandler] (1) *worker 
> Apr 28 11:29:19 de.eq3.cbcs.vertx.management.VertxManager INFO  [Thread-0] SYSTEM: added for deployment [LegacyInitializion] (1)  
> Apr 28 11:29:19 de.eq3.cbcs.vertx.management.VertxManager INFO  [Thread-0] SYSTEM: deploying 32 classes to Vert.x 
> Apr 28 11:29:19 de.eq3.cbcs.vertx.management.VertxManager INFO  [Thread-0] SYSTEM: 32 VertxDeployers initialized 
> Apr 28 11:29:19 de.eq3.cbcs.vertx.management.VertxManager INFO  [vert.x-eventloop-thread-2] SYSTEM: start of CyclicSmokeDetectorAwakening succeeded (4f106515-774a-4c9d-bf1b-ad6d7c6b6248) 
> Apr 28 11:29:19 de.eq3.cbcs.vertx.management.VertxManager INFO  [vert.x-eventloop-thread-4] SYSTEM: start of TransactionSubsystemHandler succeeded (8b156004-9fd7-4147-8ebd-980d186ab38c) 
> Apr 28 11:29:19 de.eq3.cbcs.vertx.management.VertxManager INFO  [vert.x-eventloop-thread-3] SYSTEM: start of HMIPTRXWriterWorker succeeded (5bdede56-6035-41a4-b876-ab3d0946fe13) 
> Apr 28 11:29:19 de.eq3.cbcs.vertx.management.VertxManager INFO  [vert.x-eventloop-thread-1] SYSTEM: start of AccessPointElectroCardioGram succeeded (ee91e0b6-80e9-4d62-b64c-71e45cca799d) 
> Apr 28 11:29:19 de.eq3.cbcs.vertx.management.VertxManager INFO  [vert.x-eventloop-thread-1] SYSTEM: start of DeviceInclusionDefaultConfigurationChanger succeeded (abbe4265-e443-4a8f-b823-2c1acae13ca6) 
> Apr 28 11:29:19 de.eq3.cbcs.vertx.management.VertxManager INFO  [vert.x-eventloop-thread-3] SYSTEM: start of AccessPointKeyServerWorker succeeded (2d10a9b1-67bf-4f1a-abd7-e779a179b3f1) 
> Apr 28 11:29:19 de.eq3.cbcs.server.core.vertx.KeyServerWorker ERROR [vert.x-worker-thread-3] Missing key server configuration parameter (Network.Key) for  mode: KEYSERVER_LOCAL 
> Apr 28 11:29:19 de.eq3.cbcs.vertx.management.VertxManager INFO  [vert.x-eventloop-thread-6] SYSTEM: start of KeyServerWorker succeeded (41198673-abbd-4a06-9cb8-4d799f8c3e3e) 
> Apr 28 11:29:19 de.eq3.cbcs.lib.remotecommadapter.device.security.RouterKeyServerWorker ERROR [vert.x-worker-thread-0] Missing key server configuration parameter (Network.Key) for  mode: KEYSERVER_LOCAL 
> Apr 28 11:29:19 de.eq3.cbcs.vertx.management.VertxManager INFO  [vert.x-eventloop-thread-5] SYSTEM: start of LegacyBlindLevelCorrectionHandler succeeded (c61e0cae-581a-4043-88da-346e89ede5d7) 
> Apr 28 11:29:19 de.eq3.cbcs.vertx.management.VertxManager INFO  [vert.x-eventloop-thread-7] SYSTEM: start of RouterKeyServerWorker succeeded (ed39ab8a-b530-432d-897c-de2e1c656779) 
> Apr 28 11:29:20 de.eq3.cbcs.server.core.live_otau.DeviceLiveUpdateSubsystem INFO  [vert.x-eventloop-thread-0] SYSTEM: DeviceLiveUpdateSubsystem started 
> Apr 28 11:29:20 de.eq3.cbcs.vertx.management.VertxManager INFO  [vert.x-eventloop-thread-2] SYSTEM: start of DeviceLiveUpdateSubsystem succeeded (e4c1b748-bb7a-4b91-9683-cb4ba0f54f54) 
> Apr 28 11:29:20 de.eq3.cbcs.vertx.management.VertxManager INFO  [vert.x-eventloop-thread-0] SYSTEM: start of CheckDeviceExistHandler succeeded (ab7be0d5-7ef1-46d8-9e5c-3e28d2134472) 
> Apr 28 11:29:20 de.eq3.cbcs.vertx.management.VertxManager INFO  [vert.x-eventloop-thread-0] SYSTEM: start of KryoPersistenceWorker succeeded (83384de4-0a3a-42f9-b9b6-0f481278f6c7) 
> Apr 28 11:29:20 de.eq3.cbcs.vertx.management.VertxManager INFO  [vert.x-eventloop-thread-7] SYSTEM: start of DeviceBackgroundUpdateSubsystem succeeded (2ffa03ee-096f-477e-b196-ba834cccea97) 
> Apr 28 11:29:20 de.eq3.cbcs.vertx.management.VertxManager INFO  [vert.x-eventloop-thread-1] SYSTEM: start of LocalServerPersistentDataLoader succeeded (c148953f-b2ff-4329-9c20-d85d0466be1b) 
> Apr 28 11:29:22 de.eq3.cbcs.vertx.management.VertxManager INFO  [vert.x-eventloop-thread-5] SYSTEM: start of RemoteCommAdapterInitialization succeeded (dad34a3c-0a95-41af-9be7-b0ca1623477a) 
> Apr 28 11:29:22 de.eq3.cbcs.server.core.otau.util.FirmwareLoaderFileSystem INFO  [vert.x-worker-thread-0] SYSTEM: Firmware update directory is set to /etc/config/firmware 
> Apr 28 11:29:22 de.eq3.cbcs.vertx.management.VertxManager INFO  [vert.x-eventloop-thread-5] SYSTEM: start of AccessPointAuthorisationHandler succeeded (d3fbc369-1549-426c-83a4-37b507c2f6ac) 
> Apr 28 11:29:22 de.eq3.cbcs.vertx.management.VertxManager INFO  [vert.x-eventloop-thread-7] SYSTEM: start of AccessPointMessageDispatcher succeeded (f370ba91-f196-4a48-931e-4c989f4cd942) 
> Apr 28 11:29:22 de.eq3.cbcs.vertx.management.VertxManager INFO  [vert.x-eventloop-thread-7] SYSTEM: start of WebSocketManager succeeded (fdead227-ec1f-423c-99e5-500b76b5699e) 
> Apr 28 11:29:22 de.eq3.cbcs.vertx.management.VertxManager INFO  [vert.x-eventloop-thread-0] SYSTEM: start of FirmwareLoaderFileSystem succeeded (287f806b-7395-4860-8c1f-343eed4bcab9) 
> Apr 28 11:29:22 de.eq3.cbcs.vertx.management.VertxManager INFO  [vert.x-eventloop-thread-1] SYSTEM: start of IncomingHMIPFrameHandler succeeded (d62fbaab-af49-4af9-82ba-057de218f013) 
> Apr 28 11:29:22 de.eq3.cbcs.vertx.management.VertxManager INFO  [vert.x-eventloop-thread-4] SYSTEM: start of AccessPointWatchdog succeeded (cc86d728-a204-431b-acac-7a654c42bef8) 
> Apr 28 11:29:22 de.eq3.cbcs.vertx.management.VertxManager INFO  [vert.x-eventloop-thread-5] SYSTEM: start of AccessPointCommDevice succeeded (c51d561a-4f44-49a4-b557-fa4693b58908) 
> Apr 28 11:29:22 de.eq3.cbcs.vertx.management.VertxManager INFO  [vert.x-eventloop-thread-6] SYSTEM: start of DeviceInclusionAcceptHandler succeeded (af31a1e4-0849-40a9-97d5-2b3845aa19f2) 
> Apr 28 11:29:22 de.eq3.cbcs.vertx.management.VertxManager INFO  [vert.x-eventloop-thread-3] SYSTEM: start of BackendCommandHandler succeeded (bf3fe888-75af-4f2b-bce6-bfba3491d574) 
> Apr 28 11:29:22 de.eq3.cbcs.vertx.management.VertxManager INFO  [vert.x-eventloop-thread-7] SYSTEM: start of LocalServerAdapterInitialization succeeded (e6663d94-8da8-4132-bd5a-8d78eaa85af6) 
> Apr 28 11:29:22 de.eq3.cbcs.server.local.base.internal.HMIPTRXInitialResponseListener INFO  [Thread-6] TRX adapter state 1: HMIP_TRX_App 
> Apr 28 11:29:22 de.eq3.cbcs.server.local.base.internal.HMIPTRXInitialResponseListener INFO  [Thread-6] TRX adapter application is already running or started 
> Apr 28 11:29:22 de.eq3.cbcs.server.local.base.internal.HMIPTRXInitialResponseListener INFO  [Thread-6] No NWK, try to set address ... 
> Apr 28 11:29:22 de.eq3.cbcs.server.local.base.internal.HMIPTRXInitialResponseListener INFO  [Thread-6] Try to set radio address 12507385... 
> Apr 28 11:29:22 de.eq3.cbcs.server.local.base.internal.HMIPTRXInitialResponseListener INFO  [Thread-6] Set max send attempts for 3014F711A061A7D70992B8D0 to 3 
> Apr 28 11:29:22 de.eq3.cbcs.server.local.base.internal.HMIPTRXInitialResponseListener INFO  [Thread-6] Try to get application version... 
> Apr 28 11:29:22 de.eq3.cbcs.server.local.base.internal.HMIPTRXInitialResponseListener INFO  [Thread-6] Application version 2.8.6 
> Apr 28 11:29:22 de.eq3.cbcs.server.local.base.internal.HMIPTRXInitialResponseListener INFO  [Thread-6] Bootloader version 1.0.3 
> Apr 28 11:29:22 de.eq3.cbcs.server.local.base.internal.HMIPTRXInitialResponseListener INFO  [Thread-6] hmos version 1.20.3 
> Apr 28 11:29:23 de.eq3.cbcs.server.local.base.internal.HMIPTRXInitialResponseListener INFO  [Thread-6] MCU type: Si1002_8051 
> Apr 28 11:29:23 de.eq3.cbcs.server.local.base.internal.HMIPTRXInitialResponseListener INFO  [Thread-6] Duty Cycle: 58.5 
> Apr 28 11:29:23 de.eq3.cbcs.server.local.base.internal.HMIPTRXInitialResponseListener INFO  [Thread-6] set DutyCycle limit to ffffffc8 
> Apr 28 11:29:23 de.eq3.cbcs.server.local.base.internal.HMIPTRXInitialResponseListener INFO  [Thread-6] Set Duty Cycle Limit 
> Apr 28 11:29:23 de.eq3.cbcs.server.local.base.internal.HMIPTRXInitialResponseListener INFO  [Thread-6] Current Security Counter: 535807757 
> Apr 28 11:29:23 de.eq3.cbcs.server.local.base.internal.HMIPTRXInitialResponseListener INFO  [Thread-6] Update security counter to calculation: 535807884 
> Apr 28 11:29:23 de.eq3.cbcs.server.local.base.internal.HMIPTRXInitialResponseListener INFO  [Thread-6] TRX adapter has 26 link partners 
> Apr 28 11:29:23 de.eq3.cbcs.server.local.base.internal.HMIPTRXInitialResponseListener INFO  [Thread-6] Adapter with Access Point id 3014F711A061A7D70992B8D0 initialized 
> Apr 28 11:29:23 de.eq3.cbcs.server.local.base.internal.LocalServerAdapterInitialization INFO  [Thread-6] HMIPTRXInitialResponseListener said that Adapter was initialized 
> Apr 28 11:29:24 de.eq3.cbcs.vertx.management.VertxManager INFO  [vert.x-eventloop-thread-4] SYSTEM: start of RemoteCommAdapterFinalization succeeded (d2d55971-c64b-4860-8b6a-971e1d3cd98f) 
> Apr 28 11:29:24 de.eq3.cbcs.vertx.management.VertxManager INFO  [vert.x-eventloop-thread-0] SYSTEM: start of LocalServerFirmwareUpdateInitialization succeeded (6c49664f-71ed-413e-88b2-1b12c46131b4) 
> Apr 28 11:29:24 de.eq3.cbcs.vertx.management.VertxManager INFO  [vert.x-eventloop-thread-2] SYSTEM: start of LegacyBackendNotificationHandler succeeded (1cff865c-14ca-43e4-a059-cabb28ecc2d2) 
> Apr 28 11:29:24 de.eq3.cbcs.lib.lanrouting.UdpServer INFO  [vert.x-worker-thread-0] UDP Routing configuration: trying to bind port 43438 on eth0 0.0.0.0 -> 192.168.178.24 
> Apr 28 11:29:24 de.eq3.cbcs.vertx.management.VertxManager INFO  [vert.x-eventloop-thread-2] SYSTEM: start of LegacyNotificationHandler succeeded (95afba3a-df51-4041-bd30-3fdd5c7d1043) 
> Apr 28 11:29:24 de.eq3.cbcs.legacy.bidcos.rpc.LegacyServiceHandler ERROR [vert.x-worker-thread-1] Unable to fetch information for initialization of VirtualRemoteControl 
> java.lang.NullPointerException
> 	at de.eq3.cbcs.legacy.bidcos.rpc.internal.VirtualRemoteControl.updateLinkCache(VirtualRemoteControl.java:793)
> 	at de.eq3.cbcs.legacy.bidcos.rpc.internal.VirtualRemoteControl.updateLinkCache(VirtualRemoteControl.java:784)
> 	at de.eq3.cbcs.legacy.bidcos.rpc.internal.VirtualRemoteControl.<init>(VirtualRemoteControl.java:135)
> 	at de.eq3.cbcs.legacy.bidcos.rpc.LegacyServiceHandler.<init>(LegacyServiceHandler.java:110)
> 	at de.eq3.cbcs.legacy.bidcos.rpc.internal.LegacyAPIWorker.start(LegacyAPIWorker.java:68)
> 	at io.vertx.core.AbstractVerticle.start(AbstractVerticle.java:111)
> 	at io.vertx.core.impl.DeploymentManager.lambda$doDeploy$8(DeploymentManager.java:434)
> 	at io.vertx.core.impl.ContextImpl.lambda$wrapTask$2(ContextImpl.java:337)
> 	at io.vertx.core.impl.TaskQueue.lambda$new$0(TaskQueue.java:60)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> 	at java.lang.Thread.run(Thread.java:748)
> Apr 28 11:29:24 de.eq3.cbcs.vertx.management.VertxManager INFO  [vert.x-eventloop-thread-0] SYSTEM: start of LegacyAPIWorker succeeded (74cc1297-fbb8-4a86-a88d-b21da52ed12c) 
> Apr 28 11:29:24 de.eq3.cbcs.server.core.otau.DeviceBackgroundUpdateSubsystem INFO  [vert.x-eventloop-thread-3] SYSTEM: Checking all devices on all accesspoints for updates 
> Apr 28 11:29:24 de.eq3.cbcs.server.core.otau.DeviceBackgroundUpdateSubsystem INFO  [vert.x-eventloop-thread-3] SYSTEM: There are 1 APs queued with updatable devices (RF) 
> Apr 28 11:29:24 de.eq3.cbcs.server.core.otau.DeviceBackgroundUpdateSubsystem INFO  [vert.x-eventloop-thread-3] SYSTEM: There are 0 APs queued with updatable devices (WIRED) 
> Apr 28 11:29:24 de.eq3.cbcs.lib.lanrouting.LanRoutingWorker INFO  [vert.x-worker-thread-0] AP 3014F711A061A7D70992B8D0: Could not initialize routing of access point, version is 2.8.6 
> Apr 28 11:29:24 de.eq3.cbcs.lib.lanrouting.UdpServer INFO  [vert.x-worker-thread-3] UDP Routing established on network interface eth0 : 0.0.0.0 (192.168.178.24) 
> Apr 28 11:29:24 de.eq3.cbcs.lib.lanrouting.UdpServer INFO  [vert.x-worker-thread-1] UDP Routing multi cast established on network interface eth0 : 192.168.178.24 
> Apr 28 11:29:24 de.eq3.cbcs.lib.remotecommadapter.AccessPointCommDevice INFO  [vert.x-eventloop-thread-6] SYSTEM: Started Access Point WebSocket server with port 9293 
> Apr 28 11:29:24 de.eq3.cbcs.lib.remotecommadapter.AccessPointCommDevice INFO  [vert.x-eventloop-thread-6] SYSTEM: connector open 
> Apr 28 11:29:24 de.eq3.cbcs.vertx.management.VertxManager INFO  [vert.x-eventloop-thread-6] SYSTEM: start of LanRoutingWorker succeeded (f4aaff72-d223-4a81-ae9c-9a2ce37f68ca) 
> Apr 28 11:29:25 de.eq3.cbcs.vertx.management.VertxManager INFO  [vert.x-eventloop-thread-6] SYSTEM: start of LegacyInitializion succeeded (fff7c7b0-5ec9-4256-b423-6da25ee97710) 
> Apr 28 11:29:25 de.eq3.cbcs.vertx.management.VertxManager INFO  [Thread-0] SYSTEM: initial deployment complete _____________________________________________________ 
> Apr 28 11:29:25 de.eq3.cbcs.server.local.LocalServer INFO  [Thread-0] SYSTEM: Bind XML-RPC api to port 32010 
> Apr 28 11:29:28 de.eq3.ccu.server.BaseHMServer INFO  [Thread-1] Default MaxEventLoopExecuteTime: 2000000000 
> Apr 28 11:29:28 de.eq3.ccu.server.BaseHMServer INFO  [Thread-1] Default BlockedThreadCheckInterval: 1000 
> Apr 28 11:29:28 de.eq3.ccu.server.BaseHMServer INFO  [Thread-1] Default MaxWorkerExecuteTime: 60000000000 
> Apr 28 11:29:28 de.eq3.ccu.server.BaseHMServer INFO  [Thread-1] Default EventLoopPoolSize: 8 
> Apr 28 11:29:29 de.eq3.cbcs.vertx.management.VertxManager INFO  [Thread-1] SYSTEM: added for deployment [BackendWorker] (1) *worker 
> Apr 28 11:29:29 de.eq3.cbcs.vertx.management.VertxManager INFO  [Thread-1] SYSTEM: added for deployment [GroupRequestWorker] (1) *worker 
> Apr 28 11:29:29 de.eq3.cbcs.vertx.management.VertxManager INFO  [Thread-1] SYSTEM: added for deployment [DiagramRequestWorker] (1) *worker 
> Apr 28 11:29:29 de.eq3.cbcs.vertx.management.VertxManager INFO  [Thread-1] SYSTEM: added for deployment [StorageRequestWorker] (1) *worker 
> Apr 28 11:29:29 de.eq3.cbcs.vertx.management.VertxManager INFO  [Thread-1] SYSTEM: added for deployment [DeviceFirmwareRequestWorker] (1) *worker 
> Apr 28 11:29:29 de.eq3.cbcs.vertx.management.VertxManager INFO  [Thread-1] SYSTEM: added for deployment [EnergyPriceRequestWorker] (1) *worker 
> Apr 28 11:29:29 de.eq3.cbcs.vertx.management.VertxManager INFO  [Thread-1] SYSTEM: added for deployment [CouplingRequestWorker] (1) *worker 
> Apr 28 11:29:29 de.eq3.cbcs.vertx.management.VertxManager INFO  [Thread-1] SYSTEM: added for deployment [RegaClientWorker] (1) *worker 
> Apr 28 11:29:29 de.eq3.cbcs.vertx.management.VertxManager INFO  [Thread-1] SYSTEM: added for deployment [GroupConfigurationPersistenceFileSystem] (1) *worker 
> Apr 28 11:29:29 de.eq3.cbcs.vertx.management.VertxManager INFO  [Thread-1] SYSTEM: added for deployment [HmIPGatewayManagementRequestWorker] (1) *worker 
> Apr 28 11:29:29 de.eq3.cbcs.vertx.management.VertxManager INFO  [Thread-1] SYSTEM: deploying 10 classes to Vert.x 
> Apr 28 11:29:29 de.eq3.cbcs.vertx.management.VertxManager INFO  [vert.x-eventloop-thread-4] SYSTEM: start of BackendWorker succeeded (5f173199-f5b2-41ff-9923-435df6cb160b) 
> Apr 28 11:29:29 de.eq3.cbcs.vertx.management.VertxManager INFO  [Thread-1] SYSTEM: 10 VertxDeployers initialized 
> Apr 28 11:29:29 de.eq3.cbcs.vertx.management.VertxManager INFO  [vert.x-eventloop-thread-5] SYSTEM: start of GroupConfigurationPersistenceFileSystem succeeded (3f5c268e-5214-4782-9234-699c9fa6f432) 
> Apr 28 11:29:29 de.eq3.cbcs.vertx.management.VertxManager INFO  [vert.x-eventloop-thread-3] SYSTEM: start of EnergyPriceRequestWorker succeeded (cf57dae9-1701-43f8-a938-4a4327c2ad97) 
> Apr 28 11:29:29 de.eq3.cbcs.vertx.management.VertxManager INFO  [vert.x-eventloop-thread-2] SYSTEM: start of CouplingRequestWorker succeeded (b85ddf50-4129-4225-8cfa-487a8874cce3) 
> Apr 28 11:29:29 de.eq3.cbcs.vertx.management.VertxManager INFO  [vert.x-eventloop-thread-4] SYSTEM: start of StorageRequestWorker succeeded (318ccbdc-e532-4ac0-99d4-36178696fbae) 
> Apr 28 11:29:29 de.eq3.cbcs.vertx.management.VertxManager INFO  [vert.x-eventloop-thread-5] SYSTEM: start of RegaClientWorker succeeded (382ba683-7141-4893-adb1-e583cde7bd4e) 
> Apr 28 11:29:29 de.eq3.cbcs.vertx.management.VertxManager INFO  [vert.x-eventloop-thread-3] SYSTEM: start of GroupRequestWorker succeeded (c5c30860-aea0-4434-bb2b-74df62062696) 
> Apr 28 11:29:29 de.eq3.cbcs.vertx.management.VertxManager INFO  [vert.x-eventloop-thread-5] SYSTEM: start of DiagramRequestWorker succeeded (d07eaaf1-750f-4eb2-b426-fbacc99cb426) 
> Apr 28 11:29:29 de.eq3.cbcs.vertx.management.VertxManager INFO  [vert.x-eventloop-thread-3] SYSTEM: start of DeviceFirmwareRequestWorker succeeded (6c5ec2ca-b1f4-4a03-90be-52bf4af00329) 
> Apr 28 11:29:29 de.eq3.cbcs.vertx.management.VertxManager INFO  [vert.x-eventloop-thread-2] SYSTEM: start of HmIPGatewayManagementRequestWorker succeeded (8568a238-f052-4156-ab93-5c78d5d9c28c) 
> Apr 28 11:29:29 de.eq3.cbcs.vertx.management.VertxManager INFO  [Thread-1] SYSTEM: initial deployment complete _____________________________________________________ 
> Apr 28 11:29:29 de.eq3.ccu.server.BaseHMServer INFO  [Thread-1] Starting HMServer at 127.0.0.1:39292 
> Apr 28 11:29:29 de.eq3.ccu.server.BaseHMServer INFO  [Thread-1] Read Configuration 
> Apr 28 11:29:29 de.eq3.ccu.server.BaseHMServer INFO  [Thread-1] Create Bidcos Dispatcher 
> Apr 28 11:29:30 de.eq3.ccu.server.BaseHMServer INFO  [Thread-1] InitBidCosCache 
> Apr 28 11:29:35 de.eq3.cbcs.server.core.otau.DeviceBackgroundUpdateSubsystem INFO  [vert.x-eventloop-thread-3] AP 3014F711A061A7D70992B8D0: OTAU Handler bba3ad07-5c49-4b81-be79-0e574f4487f2 continues for device(s) [3014F711A0001118A994F0E9] 
> 
> 
@koegel

This comment has been minimized.

Copy link
Author

commented Apr 28, 2019

Maybe this error in the log is also related to the problem?:

Apr 28 11:29:19 de.eq3.cbcs.server.core.vertx.KeyServerWorker ERROR [vert.x-worker-thread-3] Missing key server configuration parameter (Network.Key) for mode: KEYSERVER_LOCAL

@koegel

This comment has been minimized.

Copy link
Author

commented Apr 28, 2019

I also noticed I cannot open "Connections" or "General Settings" in "Settings" anymore. If I press the buttons for those entries the background is grayed out but no popup window shows on top like usually.

@koegel

This comment has been minimized.

Copy link
Author

commented Apr 28, 2019

I have now imported a backup file from a previously good state and the problem is solved.
Also I diffed the backup file of the broken state and the previously good state. I assume the folder ect/config/crRFD/data contains configuration data for HomematicIp devices. In this folder there was one file for a device (3014F711A0000AD8A99DDE11.dev) that had been created on the day and roughly the time the system had shown the error of this ticket. I have restored the broken state from a backup and deleted this file manually via ssh and the problem is also resolved. If it is of interest to debug this problem I can also send you the deleted file.

@jens-maus

This comment has been minimized.

Copy link
Owner

commented Apr 29, 2019

@koegel Regarding your initial problem: Please execute monit unmonitor HMIPServer and see if the regular restart of HMIPServer stops and HMIPServer continues to work fine or if after that command HMIPServer is not running at all anymore.

@koegel Regarding the additional *.dev file. This could happen when you switched RF-modules and the re-keying process was interrupted (e.g. due to a hard restart, etc.) In that case the old *.dev file from the old RF-module is not deleted properly and thus can be a problem when reimporting a backup.

@koegel

This comment has been minimized.

Copy link
Author

commented Apr 29, 2019

@koegel Regarding your initial problem: Please execute monit unmonitor HMIPServer and see if the regular restart of HMIPServer stops and HMIPServer continues to work fine or if after that command HMIPServer is not running at all anymore.

I tried and found that the HMIPServer does not succeed in starting even without monit restarting it constantly.

@koegel

This comment has been minimized.

Copy link
Author

commented Apr 29, 2019

@koegel Regarding the additional *.dev file. This could happen when you switched RF-modules and the re-keying process was interrupted (e.g. due to a hard restart, etc.) In that case the old *.dev file from the old RF-module is not deleted properly and thus can be a problem when reimporting a backup.

At this time to my best knowledge the raspberry was neither restarted nor did I switch RF-modules , so I wonder how this happened.
Just to be clear: The problem I had was not triggered by re-importing a backup but happened on my live system. It was only by diffing with an earlier backup that I found that this was a new file that was very recently created. Any by try-and-error I found that deleting this file fixes the HMIPServer start.

@jens-maus

This comment has been minimized.

Copy link
Owner

commented Apr 29, 2019

@koegel So now everything works correctly and this ticket can be closed?

@koegel

This comment has been minimized.

Copy link
Author

commented Apr 29, 2019

Yes everything works now. I am just wondering if this is maybe something also other users may see from time to time and if RaspberryMatic could maybe detect broken .dev files and delete them to help users to resolve this situation? If you think this is not something that is likely to occur again for other users please consider this problem fixed.
In any case: Thank you for your great work on RaspberryMatic!

@jens-maus

This comment has been minimized.

Copy link
Owner

commented Apr 30, 2019

As said, this only usually ocurrs if an rf module is exchanged or users switch from a ccu2 to raspberrymatic and the rekeying is interrupted. In fact this is the first time I read about this outside the rekeying context

@HMside

This comment has been minimized.

Copy link
Contributor

commented May 1, 2019

Diese dev-File Leichen entstehen scheinbar auch, sofern das Anlernen eines Geräts nicht vollständig abgeschlossen wird. Dies passiert z.B. wenn der KeyServer nicht erreichbar ist, oder die Kommunikation teilweise gestört ist. Das Gerät wird nicht in der regadom eingetragen, taucht nicht im Posteingang auf, aber das dev-File bleibt als Leiche zurück. Es sollte daher z.B. beim Neustart geprüft werden, ob alle Geräte (dev-Files) auch in regadom eingetragen wurden, ist dies nicht der Fall, sollte die Leiche gelöscht werden, damit ein erneutes anlernen möglich wird.

@jens-maus

This comment has been minimized.

Copy link
Owner

commented May 1, 2019

@HMside Das kann ich gerne für eine der nächsten Versionen vorsehen. Die Frage wäre nur wie genau man sowas abgleicht und herausfindet ob das Gerät das hinter dem dev file steckt auch wirklich nicht in der regadom vorhanden ist. Sollte das nicht eigentlich die Aufgabe des HMIPServer sein die dev files (da er ja die Dateien anlegt) auch aufzuräumen, oder?!?

@koegel

This comment has been minimized.

Copy link
Author

commented May 1, 2019

Ich denke da hat @jens-maus Recht, eigentlich sollte der HMIPServer überflüssige dev files abräumen. Außerdem sollte er imho die Exception graceful handeln und nicht einfach anhalten.

@jens-maus

This comment has been minimized.

Copy link
Owner

commented May 1, 2019

Deshalb reaktiviere ich dieses Ticket mal und flagge es als upstream issue.

@jens-maus jens-maus reopened this May 1, 2019

@derkopp

This comment has been minimized.

Copy link

commented Jun 4, 2019

Ich habe ebenfalls das Problem. Wie kann ich feststellen, welche dev file gelöscht werden muss?

@koegel

This comment has been minimized.

Copy link
Author

commented Jun 5, 2019

Ich habe das nur Anhand des Zeitstempels vermutet. Die Datei wurde zeitlich relativ nahe zum Zeitpunkt des Fehlers erzeugt. Ich habe sie daher probeweise in einen anderen Ordner verschoben und den HMIPServer neu gestartet .

@derkopp

This comment has been minimized.

Copy link

commented Jun 5, 2019

Habe ich ähnlich gemacht, Datei umbenannt und neugestartet. Bisher ohne erneuten Fehler.

@HMside

This comment has been minimized.

Copy link
Contributor

commented Jun 6, 2019

@jens-maus
im Grunde muss man lediglich einen Abgleichen aller SGTIN.dev Files und den im regedom-File eingetragen SGTINs machen. Alle SGTINs der dev-Files, welche nicht im regadom-File eingetragen sind müssen gelöscht werden.

Besser wäre es selbstverständlich, wenn der HMServer bei einem misslungenen Anlernversuch das dev-File direkt wieder löschen.

Des weiteren habe ich auch schon Backups gesehen, wo die ap und apkx Files doppelt vorhanden waren und zwar bei reinen Funk Systemen (ohne HmIP-DRAP). Ich vermute, das dies durch einen Zentralen, oder auch Funkmodul Wechsel verursacht wird. Auch hier sollte eine Prüfung erfolgreich.

@jens-maus

This comment has been minimized.

Copy link
Owner

commented Jun 6, 2019

@HMside
Das ist in der Tat ein sehr guter hilfreicher Hinweis! Ich denke so könnte man in der Tat z.B. in den HMServer startup Skript eine routine einfügen die alle Dateien unter /etc/config/crRFD/data mit denen die in einem <devadr> tag in der homematic.regadom benannt sind vergleicht und dann ggf. die Dateien umbenennt die nicht in der regadom Datei anhand ihrer SIGTIN auftauchen.

jens-maus added a commit that referenced this issue Jun 7, 2019

added a new "checkHmIPdevices.sh" helper script which will be
automatically started before starting HMIPServer and which will try to
check if a *.dev, *.ap, *.apkx file should be moved away into an "old"
folder so that upon HMIPServer startup only device files which are actually
correctly referenced in the global homematic.regadom database are
present. This refs #613.
@jens-maus

This comment has been minimized.

Copy link
Owner

commented Jun 7, 2019

So, inzwischen habe ich einmal solch ein besagtes Hilfskraft erstellt (siehe https://github.com/jens-maus/RaspberryMatic/blob/master/buildroot-external/overlay/base-raspmatic/bin/checkHmIPdevices.sh). Das sollte nach meinem Verständnis automatisch bei hochfahren des HMIPServer nun wie von @HMside vorgeschlagen die Konsistenz der *.dev *.ap *.apkx Dateien gegenüber der Homematic.regadom überprüfen und dann ggf. die Dateien in einen old Ordner verschieben sodass die dem HMIPServer nicht mehr in den Weg kommen.

Bitte diesen Skript gerne mal runterladen und unter RaspberryMatic ausführen, dann sollte er ausspucken ob es ggf. ein problem gibt. Wenn es keine Einwände oder Probleme beim testen des Skriptes gibt werde ich diesen dann für die nächste RaspberryMatic Version zur integration vorsehen und automatisch vor dem Start des HMIPServer ausführen lassen.

@jens-maus jens-maus added this to the next release milestone Jun 7, 2019

@koegel

This comment has been minimized.

Copy link
Author

commented Jun 15, 2019

Ich habe es ausprobiert und das Script findet (leider) zwei Treffer. Die beiden zugehörigen Dateien sind im Vergleich zu anderen .dev Dateien auch eher kurz ({...} = HEX-Zeichenfolgen):

^A^@de.eq3.cbcs.persistence.kryo.VersionendPersistentDevic�^A^A^A�^Ade.eq3.cbcs.
{...}�{...}�{...}�^C^@^@^A(^@^@^@^A^@^A^@^L^

@jens-maus

This comment has been minimized.

Copy link
Owner

commented Jun 15, 2019

@koegel Dann mal den Script mit der Option -f aufrufen und er wird diese Dateien in einen old Subfolder verschieben. Danach dann HMIPServer Neustarten und dann sollte die Zentrale wieder i.O. sein.

@koegel

This comment has been minimized.

Copy link
Author

commented Jun 15, 2019

@koegel Dann mal den Script mit der Option -f aufrufen und er wird diese Dateien in einen old Subfolder verschieben. Danach dann HMIPServer Neustarten und dann sollte die Zentrale wieder i.O. sein.

Ich habe aktuell eigentlich kein Problem. Bist du sicher dass die beiden Dateien überflüssig sind?

@jens-maus

This comment has been minimized.

Copy link
Owner

commented Jun 16, 2019

Probieren geht über studieren würde ich sagen ;) und wäre schon eine hilfe für den nächsten Release zu erfahren ob das skript macht was es soll. Und wenn es danach probleme gibt oder Geräte weg sind sind die ja wieder schnell zurückkopiert.

@koegel

This comment has been minimized.

Copy link
Author

commented Jun 17, 2019

OK :), habe es ausprobiert. Scheint bisher keine negativen Seiteneffekte zu haben. Ich werde mich hier nochmal melden falls es doch noch Probleme gibt.

@jens-maus

This comment has been minimized.

Copy link
Owner

commented Jun 17, 2019

Gut, danke. dann denke ich sollte es für den nächsten Release so i.O. gehen.

@jens-maus jens-maus closed this Jun 17, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.