I think the problem can be caused by your item definitions. “Number” is no longer OK. You have the add the unit, e.g. Number:Temperature for temperatures.
I think the rrd4j problem has a different reason and is not caused by the binding (maybe also caused by the item definitions).
Ok it seems slowly I understand how it works. Only replacing “number” by “number:temprature” was not the solution until now.
Is it possible that I first have to define the channel type “temperature” like in the documentation?
If yes where must it be done?
Hi Johannes,
since OH 3 I am no longer using text files to define things and items. I like the idea of the semantic model that makes creating nice UIs much easier. Therefore I would have to read the docs before I could help you with channel and items definitions.
Martin
now I found some other issue in the log files which can be a possible reason:
10:57:52.065 [WARN ] [nternal.handler.HomematicThingHandler] - Value for datapoi nt HmDatapoint[name=CONF_BUTTON_TIME,value=255,defaultValue=255,type=INTEGER,min Value=1,maxValue=254,options=null,readOnly=false,readable=true,unit=minutes,desc ription=CONF_BUTTON_TIME,info=null,paramsetType=MASTER,virtual=false,trigger=fal se] is outside of valid range, using default value for config.
Has some body any idea whta that mean?
I got all my other devices back to work. But only the weather sensor still only updates the values one time after restarting openhab
By the way defining the weather sensor via UI leads to exaclty the same problem. Additionally some of the Homematic devices are not controlable by alexa while others are. I’m realy getting confused by OH3
I just got the information in another thread with a similar problem that probably rrd4j caused the problem:
Maybe it is the same kind of problem and you can solve it by fixing the rrd4j database
Hi Martin,
thank you for your continued support and thank you for pointing this out. I have done “fix-permissions”, deleted the *.persist and uninstalled the rrd4j binding. Unfortunately this did not help. Meanwhile I think there is a problem with the homematic binding. In the log files I found the following:
2022-10-01 17:26:06.659 [INFO ] [ommunicator.AbstractHomematicGateway] - HmGatewayInfo[id=CCU,type=CCU2,firmware=2.47.20,address=OEQ0457574,rf=true,wired=false,hmip=true,cuxd=false,group=true]
2022-10-01 17:26:25.654 [INFO ] [ng.homematic.internal.misc.MiscUtils] - Datapoint name ‘${sysVarAlarmZone1}’ contains invalid characters, new Datapoint name ‘_sysVarAlarmZone1’
2022-10-01 17:26:25.655 [INFO ] [ng.homematic.internal.misc.MiscUtils] - Datapoint name ‘${sysVarPresence}’ contains invalid characters, new Datapoint name ‘_sysVarPresence’
2022-10-01 17:26:26.225 [WARN ] [ternal.handler.HomematicThingHandler] - Value for datapoint HmDatapoint[name=CONF_BUTTON_TIME,value=255,defaultValue=255,type=INTEGER,minValue=1,maxValue=254,options=null,readOnly=false,readable=true,unit=minutes,description=CONF_BUTTON_TIME,info=null,paramsetType=MASTER,virtual=false,trigger=false] is outside of valid range, using default value for config.
2022-10-01 17:26:29.279 [WARN ] [ternal.handler.HomematicThingHandler] - Value for datapoint HmDatapoint[name=CONF_BUTTON_TIME,value=255,defaultValue=255,type=INTEGER,minValue=1,maxValue=254,options=null,readOnly=false,readable=true,unit=minutes,description=CONF_BUTTON_TIME,info=null,paramsetType=MASTER,virtual=false,trigger=false] is outside of valid range, using default value for config.
2022-10-01 17:26:30.110 [WARN ] [ternal.handler.HomematicThingHandler] - Value for datapoint HmDatapoint[name=CONF_BUTTON_TIME,value=255,defaultValue=255,type=INTEGER,minValue=1,maxValue=254,options=null,readOnly=false,readable=true,unit=minutes,description=CONF_BUTTON_TIME,info=null,paramsetType=MASTER,virtual=false,trigger=false] is outside of valid range, using default value for config.
but I can’t find any errors in the event.log
Also a firmware update of the CCU2 has brought nothing. I would be very grateful for any hints to narrow down the problem or possible solutions.
The problem regarding the values that are outside of the valid has been solved with OH 3.3. But I have no idea whether there might by remaining problems with text files. But if the state of all things is “Online” then this should not be a problem (see my comment here: [homematic] Binding complains about values out of range · Issue #13477 · openhab/openhab-addons · GitHub)
But what is your real problem now? Some posts ago, you mentioned problems with Alexa. Do you have problems with updates in OH Main UI or Basic UI or only with Alexa? As far as I know the configuration for Alexa has changed with 3.x.
Sorry Martin for that confusion.
I’ve still the problem, that the values of my homematic weather sensor are not updating.
This happens only one time after restart the ccu2 or openhab. When it’s running the the values does not change.
OK, let’s try it with some more trace output. Please set the log level for the Homematic binding to TRACE, then try to provoke some values changes in the weather station and see whether there is some output relatet to the weather station in openhab.log (please post it here if you can identify some output).
If the TRACE shows no information about received data then the binding probably does not receive any events from the CCU. If OH is running in a container?
Another option would be to ssh into the CCU and check the logs on this side. But I am not sure whether there can be found relevant information if it is not possible to send an event (would have to check this with my installation).
Hi Martin,
I followed your advise and set the log level for the homematic binding via the openhab console:
log:set TRACE org.openhab.binding.homematic
Now I’m getting this additional output:
09:37:18.161 [TRACE] [rnal.communicator.client.XmlRpcClient] - Client XmlRpcRequest (port 2001):
<?xml version="1.0" encoding="ISO-8859-1"?>
<methodCall><methodName>listBidcosInterfaces</methodName>
<params></params></methodCall>
09:37:18.170 [TRACE] [rnal.communicator.client.XmlRpcClient] - Client XmlRpcResponse (port 2001):
<?xml version="1.0" encoding="iso-8859-1"?>
<methodResponse><params><param>
<value><array><data><value><struct><member><name>ADDRESS</name><value>OEQ0457574</value></member><member><name>CONNECTED</name><value><boolean>1</boolean></value></member><member><name>DEFAULT</name><value><boolean>1</boolean></value></member><member><name>DESCRIPTION</name><value></value></member><member><name>DUTY_CYCLE</name><value><i4>0</i4></value></member><member><name>FIRMWARE_VERSION</name><value>2.8.6</value></member><member><name>TYPE</name><value>CCU2</value></member></struct></value></data></array></value>
</param></params></methodResponse>
Unfortunately I can’t do much with it
It is always the same. I checked the values of the weather station through the web UI of my CCU2, even if the temperature or any other value changed, there was always the same cyclic output from above
I checked if the recording is ok by operating another homematic device. This is the corresponding log:
09:51:55.591 [INFO ] [openhab.event.ItemCommandEvent ] - Item 'OG_Flur_Decke' received command OFF
09:51:55.598 [INFO ] [openhab.event.ItemStatePredictedEvent] - Item 'OG_Flur_Decke' predicted to become OFF
09:51:55.604 [DEBUG] [nternal.handler.HomematicThingHandler] - Received command 'OFF' for channel 'homematic:HM-LC-Sw1-DR:ccu2:OEQ0330832:1#STATE'
09:51:55.610 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'OG_Flur_Decke' changed from ON to OFF
09:51:55.610 [TRACE] [.converter.type.AbstractTypeConverter] - Converting type OnOffType with value 'OFF' using OnOffTypeConverter to datapoint 'OEQ0330832:1#STATE' (dpType='BOOL', dpUnit='null')
09:51:55.617 [DEBUG] [communicator.AbstractHomematicGateway] - Sending datapoint 'OEQ0330832:1#STATE' with value 'false' to gateway with id 'ccu2' using rxMode 'DEFAULT'
Interesting are the messages starting with “Received … for channel”.
Can you provide me the complete log file or at an excerpt where you would expect messages from the weather station. With log mode set to TRACE the binding writes every message it receives from the CCU to the log file. They are sometimes hard to read because they can be quite large and are in XML format. If the binding receives no messages there is definitely a communication problem.
Is the weather station the only HmIP device you are using? Or do you have other HmIP devices? If yes, do you receive events from the other devices?
I have searched the log file. The channels of the weather station are updated only once when the sitemap is reloaded (e.g. after editing and then saving).
openhab (2).log (165.6 KB)
Unfortunately the log-file is to big for uploading. I zipped it and changed .zip to .log. Just change it back for decompressing.
In fact the weather station is my only HmIP device. Is there not also a way to manually update the values or force an update?
The warnings still occur with OH 3.3.0. Please see my newest comment for that issue.
Thanks for the log. To me it seems that your OH installation does not receive any events from CCU. I can’t see any messages like this in the log (this is an example from my installation):
2022-10-08 10:49:23.983 [TRACE] [nal.communicator.server.XmlRpcServer] - Server parsed XmlRpcMessage:
This means the CCU can not send messages to port 9125 on the machine where OH is running. This is the reason why you don’t get any value updates.
Many thanks for analyzing the log-files. Unfortunately I’m a litle bit confused now. My OpenHab runs on a raspberry PI4 with openhabian. I tought this is an easy setup made especially for openhab. I googled now for I while but was not able to find some tutorials how to check an open ports. May be you can give me a hint.
I think, openHabian is really good for a simple installation of OH but it probably does not now about all ports that may be required by other devices.
I don’t know how the firewall is configured in openHabian, but you can try whether ufw is active with ufw status. If ufw is active it will display all open ports. With ufw allow you can open additional ports.
If ufw is not available, you can use iptables --list to see all rules that are configured.
Many thanks for your reply Martin. It seems there is neither ufw nor iptables installed on my system. So I installed ufw with: sudo apt-get install ufw
Active ufw with: sudo ufw enable
and allowed any connection: sudo ufw default allow
Now any incomming connection or request should be allowed. Shouldn’t it?
sudo ufw app list
shows the following list:
Available applications:
AIM
Bonjour
CIFS
CUPS
DNS
Deluge
IMAP
IMAPS
IPP
KTorrent
Kerberos Admin
Kerberos Full
Kerberos KDC
Kerberos Password
LDAP
LDAPS
LPD
MSN
MSN SSL
Mail submission
NFS
OpenSSH
POP3
POP3S
PeopleNearby
SMTP
SSH
Samba
Socks
Telnet
Transmission
Transparent Proxy
VNC
WWW
WWW Cache
WWW Full
WWW Secure
XMPP
Yahoo
qBittorrent
svnserve
I really wonder why there is nothing about Homematic or something similar.
If neither ufw nor iptables was installed maybe no firewall was installed at all.
You can check the port status with ufw status verbose.
ufw app list shows only known ports, i.e. standard ports with numbers less then 1024. The binding and Homematic are using non-standard ports.
Maybe there is another possible cause for the problem: how did you connect your raspi to your network? Via WiFi or ethernet cable? I would highly recommend ethernet cable with a fixed ip address.
To verify whether the binding is listening on the correct address and port you can run: netstat -apn | grep 9125
Output should be similar to this:
tcp6 0 0 192.168.2.80:9125 192.168.2.93:59522 ESTABLISHED 12626/java
tcp6 0 0 192.168.2.80:9125 192.168.2.93:37658 ESTABLISHED 12626/java