No inital state reading for homematic devices after server restart

[openhab-bot]

From marian.k...@gmail.com on April 28, 2013 11:47:30

What steps will reproduce the problem? 1.restart openhab service What is the expected output? What do you see instead? expected: the initial state should de read from all homematic devices observed: the initial state from homematic devices is not set if homematic device state is changed, then the openhab state is change too. This is ok for temprature devices, but for devices with rarely state changes (like contact sensors) it is not ok. What version of the product are you using? On what operating system? Using openhab 1.2 on ubuntu 12.04 Please provide any additional information below. there are any warnings in openhab.log: After server restart for each device tere is a warning like 11:19:09.659 WARN o.o.b.h.i.bus. HomematicBinding [:316]- No item found for HEQ0363022:1#STATE - doing nothing. May be getting the initial state from device failed for some reasons?

Original issue: http://code.google.com/p/openhab/issues/detail?id=263

[openhab-bot]

From teichsta on April 28, 2013 03:17:05

afaik, there is no possibility to read to read the values from HM initially (see Issue 252 )

@Thomas: am i right?

Owner: thomas.letsch.de

[openhab-bot]

From kai.openhab on April 28, 2013 03:23:29

You are right that it is not possible to always read it from the devices, but it is possible for openHAB to read it from the CCU - and that's what you can see from the log. The problem is here the startup order - the Homematic binding currently tries to set the initial state at a moment, when the item file is not read by openHAB - and thus it fails setting the state. I'll support Thomas L. on how to get that right.

Status: Accepted

[openhab-bot]

From kai.openhab on May 19, 2013 06:38:49

Issue 306 has been merged into this issue.

[openhab-bot]

From kai.openhab on May 19, 2013 12:18:01

Looking at the code, I actually expect it to be related to issue 141 - as soon as issue 141 is fixed, this one here might work as well.

[openhab-bot]

From thomas.letsch.de on May 19, 2013 12:28:57

Actually I do not really understand issue 141 :-(. How about a clear binding / Item lifecycle documented in the Wiki? At least would appreciate this and could then easily integrate my init / shutdown code at the right place. Its hard for me to read that from the code and I think that might be a really valuable information for a lot of developers.

[openhab-bot]

From teichsta on August 13, 2013 08:57:37

Owner: kai.openhab
Labels: Version-1.3.0

[openhab-bot]

From kai.openhab on August 30, 2013 12:43:33

This should be fixed by this change: https://code.google.com/p/openhab/source/diff?spec=svn0df68f72d797292e313c48c26d1bccfd806649c3&r=0df68f72d797292e313c48c26d1bccfd806649c3&format=side&path=/bundles/binding/org.openhab.binding.homematic/src/main/java/org/openhab/binding/homematic/internal/config/HomematicGenericBindingProvider.java

Status: Fixed

[openhab-bot]

From ingo.the...@googlemail.com on September 13, 2013 02:17:46

I can not confirm this issue is fixed. I have a HM-Sec-RHS and after restarting openHAB the state is still unknown. I thought the state should be read from the CCU when openHAB starts. Or am I wrong?

[openhab-bot]

From kai.openhab on September 13, 2013 02:31:45

Thomas, could you investigate on this?

Status: Started
Owner: thomas.letsch.de
Labels: -Version-1.3.0

[openhab-bot]

From thomas.letsch.de on September 14, 2013 09:16:49

OK, first test in debug mode:

17:52:37.403 INFO o.o.c.internal.CoreActivator[:92] - openHAB runtime has been started (v1.4.0). 17:52:38.036 DEBUG o.o.m.i.i.ItemModelActivator[:44] - Registered 'item' configuration parser 17:52:38.038 DEBUG o.o.b.h.i.bus. HomematicBinding [:292] - allBindingsChanged provider=org.openhab.binding.homematic.internal.config.HomematicGenericBindingProvider@d975a08 17:52:38.038 DEBUG o.o.b.h.i.bus. HomematicBinding [:359] - Updating item state for items [] 17:52:38.040 DEBUG o.o.b.h.i.bus. HomematicBinding [:173] - activate OK, here the activate comes. Strangely there was an allBindingsChanged call (without items) before the bundle was activated. Anyway since the config is not read here, nothing is done in activate.

17:52:38.040 DEBUG o.o.b.h.i.bus. HomematicBinding [:268] - updated config=org.eclipse.equinox.internal.cm.ConfigurationDictionary@273c6aff OK, here the config is coming. Since the CCU and the callback server was not initialized before, this is done now. Binding is ready to work.

17:52:38.666 INFO o.o.m.c.i.ModelRepositoryImpl[:99] - Loading model 'all.items' 17:52:38.717 DEBUG o.o.m.i.i.GenericItemProvider[:154] - Read items from model 'all.items' 17:52:38.724 DEBUG o.o.b.h.i.bus. HomematicBinding [:301] - bindingChanged provider=org.openhab.binding.homematic.internal.config.HomematicGenericBindingProvider@d975a08, itemName=LivingRoom_Light_Sofa OK, it starts to read the status of the first device

17:52:40.067 DEBUG o.o.b.h.i.bus. HomematicBinding [:432] - Found device at {deviceId=GEQXXXXXX, channelId=1, parameterId=LEVEL} with value 0.0 Value was read and set.

... much more device querying

17:52:45.011 INFO runtime.busevents[:46] - LivingRoom_Light_Sofa state updated to 0.0 Initialized!

OK, for my the flow in debug mode is completely ok. Could be still some timing issue in other environments.

@Ingo: Could you please provide some logs for us to have the possibility to investigate that further?

[openhab-bot]

From astelsa...@gmail.com on September 24, 2013 03:26:56

Hi, I had the same Problem.

Configuration: LAN Adapter, XML-RPC, XPSP3, magnetic contact, rotating contact, flush-mounted switching actuator, radio outlet, Piezomodul with Homatic, Keymatic, etc

I send you a report from my sys debug and startup. There is no device feedback about the status! I wait 10 min to get ITEM Status!

Hope it helps you to find the issue A.

Attachment: openhab.log events.log

[openhab-bot]

From astelsa...@gmail.com on September 26, 2013 05:30:41

Hi again,

A Workaround is to create an TMP_Item (version 1.3.1) and change the converter doesn’t matter to what the system read all items again and it works! Same if a converter seems to do not work change the TMP_Item and after sys read all again and fine!

A.

[openhab-bot]

From ingo.the...@googlemail.com on September 26, 2013 06:08:40

Hi Thomas,

sorry for the long delay. Do you need my logs anymore or are you fine with the logs from A.?

I.

[openhab-bot]

From thomas.letsch.de on September 27, 2013 00:42:18

@ingo: the log file from astelsaras should be enough.

@astelsaras: Thanks for the logs. If I understand your workaround correctly, you just update the items file and get them re-read, right?

My first thought on this is that the CCU is not yet configured when the items are read and tried to be initialized. As a fix I will try if I can query the device states of all items when the CCU is configured.

[openhab-bot]

From astelsa...@gmail.com on September 27, 2013 10:39:43

Yes you are right Thomas its enough to change the converter of one item! Remember i dont have a CCU i have only the Lan-Adapter and a XPsp3 with XML-RPC A.

[openhab-bot]

From teichsta on November 05, 2013 14:47:54

Labels: To-Github

[teichsta]

any news on this issue?

[ssifue]

I've the same issue in 1.4 as well as in recent 1.5 snapshots.

Startup always fails, any updates from the CCU-1 after restart of the runtime cause "No ItemConverter found for item xxx" errors until a refresh is triggered by reloading the homematic items file(s). A simple "touch" on the file is enough to re-read all device infos from the CCU-1 ("o.o.b.h.i.x.XmlRpcConnectionRF[:81] - called getParamset: HEQ0406308:1, VALUES").

Please let me know if you need more specific info to debug this.

[teichsta]

could you please retest with the current Snapshot build? Kai fixed some startup issues recently. Best, Thomas E.-E. (see also #457)

[teichsta]

i assume this issue to be fixed by the "new" Homematic binding. I'll close this issue therefore. Please feel free to reopen in case. Best, Thomas E.-E.