No inital state reading for homematic devices after server restart

[GoogleCodeExporter]

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 reported on code.google.com by marian.k...@gmail.com on 28 Apr 2013 at 9:47

[GoogleCodeExporter]

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

@Thomas: am i right?

Original comment by teichsta on 28 Apr 2013 at 10:17

[GoogleCodeExporter]

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.

Original comment by kai.openhab on 28 Apr 2013 at 10:23

• Changed state: Accepted

[GoogleCodeExporter]

Issue 306 has been merged into this issue.

Original comment by kai.openhab on 19 May 2013 at 1:38

[GoogleCodeExporter]

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.

Original comment by kai.openhab on 19 May 2013 at 7:18

[GoogleCodeExporter]

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. 

Original comment by thomas.letsch.de on 19 May 2013 at 7:28

[GoogleCodeExporter]

Original comment by teichsta on 13 Aug 2013 at 3:57

• Added labels: Version-1.3.0

[GoogleCodeExporter]

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

Original comment by kai.openhab on 30 Aug 2013 at 7:43

• Changed state: Fixed

[GoogleCodeExporter]

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?

Original comment by ingo.the...@googlemail.com on 13 Sep 2013 at 9:17

[GoogleCodeExporter]

Thomas, could you investigate on this?

Original comment by kai.openhab on 13 Sep 2013 at 9:31

• Changed state: Started
• Removed labels: Version-1.3.0

[GoogleCodeExporter]

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.HomematicGenericBindingPr
ovider@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.HomematicGenericBindingPr
ovider@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?

Original comment by thomas.letsch.de on 14 Sep 2013 at 4:16

[GoogleCodeExporter]

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.

Original comment by astelsa...@gmail.com on 24 Sep 2013 at 10:26

Attachments:

• openhab.log
• events.log

[GoogleCodeExporter]

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.

Original comment by astelsa...@gmail.com on 26 Sep 2013 at 12:30

[GoogleCodeExporter]

Hi Thomas,

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

I.

Original comment by ingo.the...@googlemail.com on 26 Sep 2013 at 1:08

[GoogleCodeExporter]

@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.

Original comment by thomas.letsch.de on 27 Sep 2013 at 7:42

[GoogleCodeExporter]

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

Original comment by astelsa...@gmail.com on 27 Sep 2013 at 5:39

[GoogleCodeExporter]

Original comment by teichsta on 5 Nov 2013 at 10:47

• Added labels: To-Github

[GoogleCodeExporter]

This issue has been migrated to Github. If this issue id is greater than103 its 
id has been preserved on Github. You can open your issue by calling the URL 
https://github.com/openhab/openhab/issues/<issueid>. Issues with ids less or 
equal 103 new ids were created.

Original comment by teichsta on 17 Nov 2013 at 8:08

• Added labels: Migrated-To-Github

[GoogleCodeExporter]

see above!

Issue has been migrated to Github and should be discussed there.

Original comment by teichsta on 21 Nov 2013 at 1:51

• Changed state: Invalid