However, the Thing always get 0 since my last update to 4.3.5
There isn’t anything in the log which points me to what’s wrong with my config. I only see
21:47:02.100 [DEBUG] [rd4j.internal.RRD4jPersistenceService] - Stored ‘WaschmaschineStromverbrauch’ as value ‘0.0’ with timestamp 1750103220 in rrd4j database
Does anyone know what’s wrong with my set up all of the sudden?
Well, given the JSON you posted above, that JSONPATH should return 0. Do you have an example of a JSON where power isn’t 0 and the Thing returned 0? Without that all we can say is it’s working as expected.
Haha, you are right I didnt pay any attention to the body I posted.
I of course tested it with a value other the 0 for the power. I also changed my JSONPATH to a different Attribute like voltage wich always has a value above 0 - however I get the same result.
What the actual state of the Item? Look at the Item at Settings → Items. That will show the state without formatting or transformation.
What is it being updated to? By default, you do not see updates in events.log but you can enable those log statements by setting openhab.event.ItemStateUpdatedEvent to INFO level logging.
What you see on the page of the screenshot is a transformed view of the state. But if you just click on Settings → Items the state shown in the list of all Items there is the raw state.
That’s probably coming from restoreOnStartup, especially so close to when the Item was added. And you already know that 0 is what was stored in the database.
So far we have no evidence of what the HTTP binding is returning at all. Put the binding into debug level logging and see what the logs say about requesting and transforming the result.
One thing to note is that all transformations, including JSONPATH, work with strings. So rounding the value is not happening in the transformation.
And you are right - There is no communication between the thing and the server. Which is weird because other things are sending out requests all the time…
22:33:36.474 [TRACE] [http.internal.http.RefreshingUrlCache] - Stopped refresh task for URL ‘http://server.fritz.box:8080/SmartHomeServlet/SmartPlugConsumption/?deviceIp=192.168.178.48’
22:33:36.479 [TRACE] [l.HttpDynamicStateDescriptionProvider] - removing state description for thing http:url:WaschmaschineStromverbrauch
22:33:36.486 [INFO ] [inding.http.internal.HttpThingHandler] - Using the secure client for thing ‘http:url:WaschmaschineStromverbrauch’.
22:33:36.491 [DEBUG] [inding.http.internal.HttpThingHandler] - No authentication configured for thing ‘http:url:WaschmaschineStromverbrauch’
22:33:36.497 [TRACE] [l.HttpDynamicStateDescriptionProvider] - adding state description for channel http:url:WaschmaschineStromverbrauch:WaschmaschineStromverbrauch
22:33:36.502 [TRACE] [http.internal.http.RefreshingUrlCache] - Started refresh task for URL ‘http://server.fritz.box:8080/SmartHomeServlet/SmartPlugConsumption/?deviceIp=192.168.178.48’ with interval 60s
I also checked the logs of the receiving end - it does in fact not receive anything from the binding. The endpoint is reachable, however.
It’s all on the same machine, but I also verified that the server can reach the host server.fritz.box.
Do you have any idea how to investigate further - why isn’t the refresh task startet for the url? It works for other things…
You mean OH and this server it’s sending HTTP requests to are on the same machine? Because if that’s the case have you move OH to a different port? 8080 is OH’s default port.
I can’t offer a lot of additional ideas. I don’t do .things files so can’t comment on whether there’s a syntax error or not. The logs seem to show that it’s loaded the Thing and started the refresh. So all I can suggest is to double check the URL, port, and all that sort of stuff character by character and to compare this Thing to the working Things to see if there is some difference.
I realized, that the other things using the http binding are also not sending out any requests to receive a state, they just send out commands.
Looking further I found this thread: HTTP binding stops working after ~24hrs in OH 4.3.4 - It seems to be the same issue however I experienced in version 4.3.5 while they claim it was fixed in this version.
Anyway, I rebooted my server and now everything works fine… I hope it stays this way
Thanks for your assistance in analyzing the problem.