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.
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).
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.
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.
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.
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…
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?
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
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…
Anyone here with a step-but-setp advice for the rookie?
@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.
@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.
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…)
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…
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.
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?
