Homematic status refresh

Tags: #<Tag:0x00007f185fbdd9d0>
#1

Hi there,

sorry if this has been discussed like a hundred times before or should be obvious from the docs… - it’s not for me and I’ve been browsing the forum and other sources for more than a day now.

I’m running openhab 2.2 on a raspi 3 and raspiMatic on a separate raspberry. The connection and all works find - except that when I restart openhab, all window/door contacts show “unknown”. I got to the point of understanding that I need to send a “refresh” to the ccu2, but how exactly do I do this for all contact sensor data/values to be updated in openhab?

Any advice as “openhab/homematic for dummies” is highly appreciated at this point.

Thanks

#2
#3

Hi, thanks for the swift reply, but that’s not exactly what I’m looking for. What I’d like is to get a current status update from the CCU (which might have changed compared to what’s in the persistence).

#4

You can’t, because these things are not asked about their status, they send it by themselves. The contacts don’t listen on radio, they talk when they want to. So, persistence is your only hope.

#5

thanks again! My thought was that the ccu always has the last reported status. I understand that the windows contact only sends an update to the ccu when it’s state changes, but the ccu still holds the last reported state. My hope/expectation was that it should be possible to pull that from the ccu when openHab starts up, or when triggered.

#6

Look in the channels of your bridge thing, there might be something like “reload all from gateway”. You may have to press show all to see this. This was used to get variables from the gateway if i recall correctly. Maybe it collects some state as well.

#7

yes, there is a reload_all_from_gw, but the dummy question is, how do I trigger thar? I tried a sendCommand(reload_all_from_gateway, RefreshType.Refresh), in a system started rule, but that didn’t do the trick…

#8

quick follow-up on this with my item

Switch  HM_Reload_All_From_GW   "HM Reload all from GW" { channel="homematic:GATEWAY_EXTRAS:ccu:GWE00000000:0#RELOAD_ALL_FROM_GATEWAY" }

and the rule file that I hoped would trigger a status refresh for all CCU2 connected sensors:

import org.eclipse.smarthome.core.types.RefreshType

rule "System started"
when
    System started
then
    logInfo("RULE.SystemStarted","--> O.k. - System Started")
    sendCommand(HM_Reload_All_From_GW, RefreshType.REFRESH)
end

I do see the info in the log file, but the sendCommand doesn’t seem to do anything - at least the window contacts remain undefined until they are first triggered. What am I doing wrong, here?

#9

is there anyone with an idea or lead on this?
I might be missing the obvious, but really could need some fresh eyes on this…

#10 
HM_Reload_All_From_GW.sendCommand(ON)

is working as expected here using CCU2 gateway.

im using it within a rule which is triggered by a homematic program that is executed on every change of each system variable. the program executes a short press on one of 50 virtual keys:

Switch Homematic_Virtual_Key_1 { channel="homematic:HM-RCV-50:xxxx:BidCoS-RF:1#PRESS_SHORT" }
Switch Homematic_Reload_Variables   { channel="homematic:GATEWAY-EXTRAS-xxxx:xxxx:GWE00000000:0#RELOAD_ALL_FROM_GATEWAY" }

rule "Homematic: Reload Variables"
	when 
		Item Homematic_Virtual_Key_1 changed 
	then
		Homematic_Reload_Variables.sendCommand(ON)
end
#11

hi @rikky, thanks for the follow-up and your inputs. Sadly, it’s not doing anything for me. I have adopted your nomenclature and my system.started rule now reads like

rule "System started"
when
    System started
then
    HM_Reload_All_From_GW.sendCommand(ON)
    logInfo("RULE.SystemStarted","<-- System Started")
end

The item is defined with

Switch  HM_Reload_All_From_GW   "HM Reload all from GW" { channel="homematic:GATEWAY_EXTRAS:ccu:GWE00000000:0#RELOAD_ALL_FROM_GATEWAY" }

Once the rule is saved, the trace log shows the System Started message, but nothing else, so it seems as if the command is never being sent?! That said, when I check in karaf console the HM_Reload_ALL_From_GW has a state “ON”. I’m puzzled… :frowning:

Anyone here with a step-but-setp advice for the rookie?

#12

@jjk just my simple thoughts, i don’t have a Homematic installation.

  1. GATEWAY_EXTRAS != GATEWAY-EXTRAS-CCU2
  2. ccu != ccu2

Didn’t you say CCU2, so shouldn’t it look something like this.

GATEWAY-EXTRAS-CCU2:ccu2:GWE00000000:0#RELOAD_ALL_FROM_GATEWAY

Have a look in PaperUI how the Channel is actualy called. Foto from here

#13

@Josar, thanks for the hint! I’ve tried it with both, ccu and ccu2, but that doesn’t make any difference. Interestingly, the sensors show up correctly once triggered, so I am assuming the config is o.k. What I did notice, though is that the GATEWAY_EXTRAS thing is not initialized:

homematic:GATEWAY-EXTRAS-CCU:ccu2:GWE00000000 (Type=Thing, Status=OFFLINE (CONFIGURATION_ERROR): Device with address 'GWE00000000' not found on gateway 'ccu2', Label=null, Bridge=homematic:bridge:ccu2)

All other things are initialized o.k and are showing online.

#14

@jjk please post a picture of your Gateway-Extras thing from paperUI. And maybe look in the log if there is a something which hints to the gateway initialization.

#15

@Josar, a pic is attached.

GATEWAY-EXTRAS
GATEWAY-EXTRAS.jpg1070×183 14.9 KB

I’ve tried to find a hint in the trace log, but I couldn’t find anything (although the amount of trace info is huge, so I might have missed something…)

#16

o.k., for what it’s worth, I have deleted all homematic configs, uninstalled and re-installed the homematic binding and then added everything via paperUI only (no config files). However, the GATEWAY-EXTRAS never showed up in the list of things (all other sensors and the virtual remotes did) and I simply can’t install that thing…

Any idea anyone?

#17

@jjk sorry wrong thread. Now the right Info.

No variables and scripts in GATEWAY-EXTRAS

The gateway autodetection of the binding can not clearly identify the gateway and falls back to the default implementation. Use the gatewayType=ccu config to force the binding to use the CCU implementation.

#18

@Josar I saw that thread and the gateway thing is configured with gatewayType=ccu in paperUI already. still, no GATEWAY-EXTRAS… :frowning:

#19

update: after deleting all hue items from the RasperryMatic CCU, the GATEWAYS-EXTRAS thing magically showed up in openhab.

#20

I had the same issue after installing new hue bridge to my CCU2 (FW 2.31.25).
Changing status from openhab to CCU worked, but updates from CCU to openhab did not work.
GATEWAY-EXTRAS-CCU never got online since Philips Hue bridge was installed at CCU.
Im using openhabian with latest updates.

The reason seems to be the fact that Philips Hue things use serial numbers with spaces, which seems to annoy the openhab homematic binding.

Found this exception in openhab.log:
2018-03-27 20:43:48.011 [ERROR] [ommunicator.AbstractHomematicGateway] - UID segment ‘HU-Philips hue’ contains invalid characters. Each segment of the UID must match the pattern
[A-Za-z0-9_-].
java.lang.IllegalArgumentException: UID segment ‘HU-Philips hue’ contains invalid characters. Each segment of the UID must match the pattern [A-Za-z0-9_-].
at org.eclipse.smarthome.core.thing.UID.validateSegment(UID.java:96) [116:org.eclipse.smarthome.core.thing:0.10.0.b1]
at org.eclipse.smarthome.core.thing.UID.(UID.java:74) [116:org.eclipse.smarthome.core.thing:0.10.0.b1]
at org.eclipse.smarthome.core.thing.ThingUID.(ThingUID.java:60) [116:org.eclipse.smarthome.core.thing:0.10.0.b1]
at org.openhab.binding.homematic.internal.discovery.HomematicDeviceDiscoveryService.deviceDiscovered(HomematicDeviceDiscoveryService.java:135) [212:org.openhab.binding.homematic:2.2.0]
at org.openhab.binding.homematic.handler.HomematicBridgeHandler.onDeviceLoaded(HomematicBridgeHandler.java:275) [212:org.openhab.binding.homematic:2.2.0]
at org.openhab.binding.homematic.handler.HomematicBridgeHandler.onNewDevice(HomematicBridgeHandler.java:250) [212:org.openhab.binding.homematic:2.2.0]
at org.openhab.binding.homematic.internal.communicator.AbstractHomematicGateway.newDevices(AbstractHomematicGateway.java:648) [212:org.openhab.binding.homematic:2.2.0]
at org.openhab.binding.homematic.internal.communicator.server.RpcResponseHandler.handleNewDevice(RpcResponseHandler.java:104) [212:org.openhab.binding.homematic:2.2.0]
at org.openhab.binding.homematic.internal.communicator.server.RpcResponseHandler.handleMethodCall(RpcResponseHandler.java:53) [212:org.openhab.binding.homematic:2.2.0]
at org.openhab.binding.homematic.internal.communicator.server.XmlRpcServer$ResponseHandler.handle(XmlRpcServer.java:119) [212:org.openhab.binding.homematic:2.2.0]
at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134) [87:org.eclipse.jetty.server:9.3.22.v20171030]
at org.eclipse.jetty.server.Server.handle(Server.java:534) [87:org.eclipse.jetty.server:9.3.22.v20171030]
at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:333) [87:org.eclipse.jetty.server:9.3.22.v20171030]
at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:251) [87:org.eclipse.jetty.server:9.3.22.v20171030]
at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:283) [79:org.eclipse.jetty.io:9.3.22.v20171030]
at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:108) [79:org.eclipse.jetty.io:9.3.22.v20171030]
at org.eclipse.jetty.io.SelectChannelEndPoint$2.run(SelectChannelEndPoint.java:93) [79:org.eclipse.jetty.io:9.3.22.v20171030]
at org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.executeProduceConsume(ExecuteProduceConsume.java:303) [90:org.eclipse.jetty.util:9.3.22.v20171030]
at org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.produceConsume(ExecuteProduceConsume.java:148) [90:org.eclipse.jetty.util:9.3.22.v20171030]
at org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.run(ExecuteProduceConsume.java:136) [90:org.eclipse.jetty.util:9.3.22.v20171030]
at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:671) [90:org.eclipse.jetty.util:9.3.22.v20171030]
at org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:589) [90:org.eclipse.jetty.util:9.3.22.v20171030]
at java.lang.Thread.run(Thread.java:748) [?:?]

Maybe the Philips UIDs could be mangled by the homematic binding to become compatible to the expected regular expression?