2022-08-13 20:43:17.604 [DEBUG] [ommunicator.AbstractHomematicGateway] - Received new (Boolean) value 'true' for 'OEQ0293481:1#WORKING' from gateway with id '12a3e0fbfc'
2022-08-13 20:43:17.606 [DEBUG] [ommunicator.AbstractHomematicGateway] - Received new (Integer) value '1' for 'OEQ0293481:1#DIRECTION' from gateway with id '12a3e0fbfc'
2022-08-13 20:43:21.361 [DEBUG] [ommunicator.AbstractHomematicGateway] - Received new (Double) value '0.5' for 'OEQ0293481:1#LEVEL' from gateway with id '12a3e0fbfc'
What can I do? It is a bug from this release?
After a reboot the bindig works for 1 or 2 Days again correct…
I have checked the changelog and for 3.3 there have not been relevant modifications in the binding’s connect handling. The last bigger changes were implemented and released with 3.2.
In my environment, 3.3 works fine together with Homematic. But there are two situations where I also have problems with HmIP devices:
When I have to restart Raspberrymatic because of updates I also have to restart OH resp. the binding because the connection to HmIP devices is not restored (in my opinion the is at least partially a problem of the handling of HmIP devices in Homematic itself).
During development test I often have more than one active connections to Raspberrymatic. In this case I often got problems with HmIP devices but only after some hours or days. But in this case I often have to restart Raspberrymatic too.
Do you have an idea when the connection got lost but not restored? Maybe because your router is restarted and the network was down?
Can you enable the Debug log mode for the binding. “Move” the blingds to 50% and then send the excerpt from the logfile. Maybe there is some sort of rounding problem.
I assume NEQ1369538 is the blinds device. Maybe it will be necessary to create a log with TRACE level to get even more information. I will have to investigate the changes that have been made to the binding between 3.2 and 3.3. I can’t remember of any change that could cause this kind of problem.
Can you give me some more information about the configuration? Did you configure “State Description Meta Data”?
Docker seems to cause sometimes problem. Please make sure that you have configured the callback network address in the bridge configuration and set it to the ip address of the machine running docker.
Please excuse my later reaction, I was quite busy the last days.
I had a look into the TRACE output and I can see that the binding correctly receives values from the blind.
I am not absolutely sure, but maybe the displayed level value is set to a wrong value when you stop the movement. What happens if the blind is moving? Is the displayed value for level changing?
Hi, im busy too, no Problem.
the problem is still there.
2022-08-30 21:29:34.349 [DEBUG] [ommunicator.AbstractHomematicGateway] - Received new (Integer) value ‘0’ for ‘00281D89B3C94B:1#ACTUAL_TEMPERATURE_STATUS’ from gateway with id ‘12a3e0fbfc’
2022-08-30 21:29:34.351 [DEBUG] [ommunicator.AbstractHomematicGateway] - Received new (Double) value ‘28.6’ for ‘00281D89B3C94B:1#ACTUAL_TEMPERATURE’ from gateway with id ‘12a3e0fbfc’
2022-08-30 21:29:34.428 [DEBUG] [ommunicator.AbstractHomematicGateway] - Received new (Integer) value ‘0’ for ‘00281D89B3C94B:1#ACTUAL_TEMPERATURE_STATUS’ from gateway with id ‘12a3e0fbfc’
2022-08-30 21:29:34.429 [DEBUG] [ommunicator.AbstractHomematicGateway] - Received new (Double) value ‘28.6’ for ‘00281D89B3C94B:1#ACTUAL_TEMPERATURE’ from gateway with id ‘12a3e0fbfc’
this is a HmIP-STE2-PCB. The Sensor is only a example. The value in Openhab is frozen. I have the Problem with all devices. The devices became no information over changes.
after a restart from the homematic bridge, the value is ok for one time.
I use the devices for a longe time, I have no Problem with OH an Homematic…
If the values are only updated after a OH restart then the binding does not receive update events from the CCU. After a restart the binding explicitly requests the data from the CCU. Then it registers itself as a receiver for state updates.
As you are running OH in a docker container the problem is mostly caused by the wrong callback address.Please check the bridge configuration and the setting of the callback address. The address configured here must be the address of the machine where you are running docker. Or it is a problem with the docker configuration itself. I have never tried running OH in docker, so I can’t tell you exactly what maybe wrong.
But if OH does not update any values there is most likly a communication problem between the CCU and OH.
I am running OH in Docker. but this has been going on for almost a year with no change and no problems.
Since OH 3.3 no longer updates the values, but in the log
In the bridge I have entered the IP of the host. But I have already tried everything possible here, without success.
In the log I see a change in values, but not in the Openhab GUI, how can be this?
since there seems to be a problem with registering as a recipient, how can I go about looking for the problem?
If there are entries in the log then the CCU is able to send updates to the binding and the binding receives them.
You have written that other things also do not net value updates. Do you see log entries from them?
Maybe the problem has to do with a problem in the JSONDB and a problem with the Thing IDs and Bridge IDs. I remember another problem here in the forum that was caused by the JSONDB and IDs.
In this case the JSONDB entries had to patched manually to solve the problem.
You could try the following: make a backup of the JSONDB, delete Homematic things (maybe only one or two), delete the Homeatic gateway bridge. Then create everything anew and test whether the values are now correctly displayed.
Sorry, I meant the JSONDB where OH stores all settings and not the persistency service. It is located under userdata/jsondb.
but the deletion from the bridge is not the solution. I test it last week…
Did you also delete the bridge completely and created it anew? If the log shows received value changes but the items values are not changed without any error messages, then the problem can be caused by a configuration problem that has been introduced by one of the OH updates.
Hmm, that’s really bad. The log file was not really helpful. I probably have to add some additional log output to it. Does the event.log contains entries about received updates that are not processed by the binding?
If OH receives events about updates from the CCU the connection and the event registration is OK.
If entries in event.log are missing than it maybe a communication problem. In this case you could enable a more details loggin on the CCU (Einstellungen / Zentralenwartung / Fehlerprotokoll). There you could set the log level for IP to TRACING, wait some time (until something happens that is not visible in OH) and then download the log from the CCU. Maybe this log contains helpful information.