Unsupported HTTP Media Type after upgrade to 3.2

djpsycho82 · December 27, 2021, 9:25am

After upgrade from 3.1 to 3.2, I got this error in the logfile due to some rule (see below):

2021-12-27 10:06:55.917 [WARN ] [org.apache.cxf.jaxrs.impl.WebApplicationExceptionMapper ] - javax.ws.rs.ClientErrorException: HTTP 415 Unsupported Media Type

	at org.apache.cxf.jaxrs.utils.SpecExceptions.toHttpException(SpecExceptions.java:117)

	at org.apache.cxf.jaxrs.utils.ExceptionUtils.toHttpException(ExceptionUtils.java:168)

	at org.apache.cxf.jaxrs.utils.JAXRSUtils.findTargetMethod(JAXRSUtils.java:565)

	at org.apache.cxf.jaxrs.interceptor.JAXRSInInterceptor.processRequest(JAXRSInInterceptor.java:182)

	at org.apache.cxf.jaxrs.interceptor.JAXRSInInterceptor.handleMessage(JAXRSInInterceptor.java:79)

	at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:308)

	at org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:121)

	at org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(AbstractHTTPDestination.java:265)

	at org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:234)

	at org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:208)

	at org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:160)

	at org.apache.cxf.transport.servlet.CXFNonSpringServlet.invoke(CXFNonSpringServlet.java:225)

	at org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:298)

	at org.apache.cxf.transport.servlet.AbstractHTTPServlet.doPut(AbstractHTTPServlet.java:234)

	at javax.servlet.http.HttpServlet.service(HttpServlet.java:710)

	at org.apache.cxf.transport.servlet.AbstractHTTPServlet.service(AbstractHTTPServlet.java:273)

	at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:799)

	at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:550)

	at org.ops4j.pax.web.service.jetty.internal.HttpServiceServletHandler.doHandle(HttpServiceServletHandler.java:71)

	at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)

	at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:602)

	at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)

	at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:235)

	at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1624)

	at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:233)

	at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1434)

	at org.ops4j.pax.web.service.jetty.internal.HttpServiceContext.doHandle(HttpServiceContext.java:294)

	at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:188)

	at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:501)

	at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1594)

	at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:186)

	at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1349)

	at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)

	at org.ops4j.pax.web.service.jetty.internal.JettyServerHandlerCollection.handle(JettyServerHandlerCollection.java:82)

	at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)

	at org.eclipse.jetty.server.Server.handle(Server.java:516)

	at org.eclipse.jetty.server.HttpChannel.lambda$handle$1(HttpChannel.java:388)

	at org.eclipse.jetty.server.HttpChannel.dispatch(HttpChannel.java:633)

	at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:380)

	at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:277)

	at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:311)

	at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:105)

	at org.eclipse.jetty.io.ChannelEndPoint$1.run(ChannelEndPoint.java:104)

	at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:338)

	at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:315)

	at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:173)

	at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:131)

	at org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:386)

	at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:883)

	at org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.run(QueuedThreadPool.java:1034)

	at java.base/java.lang.Thread.run(Thread.java:829)

It get’s triggered because I restart some things via a rule file. (The binding doesn’t always enable the things after openhab restart, so i check it and disable/enable the thing)

The way i do it is like this (i found it here on the forum):

    val headers = newHashMap("Authorization" -> "Bearer oh.?????.xxxxxxxxxxxxxxxxxxxxxxxxxxxx", "WWW-Authenticate"-> "Basic")
    var statusWoonkamer = getThingStatusInfo("plugwiseha:zone:adam:PW_Woonkamer_zone").getStatus()
    var statusKantoor = getThingStatusInfo("plugwiseha:zone:adam:PW_Kantoor_zone").getStatus()
    var statusVloerverwarming = getThingStatusInfo("plugwiseha:appliance_pump:adam:PW_Vloerverwarmingspomp").getStatus()
    var statusTom = getThingStatusInfo("plugwiseha:appliance_valve:adam:PW_TomWoonkamer").getStatus()
    var statusKetel = getThingStatusInfo("plugwiseha:appliance_boiler:adam:PW_Ketel").getStatus()



    if (statusWoonkamer.toString != "ONLINE"){
        sendHttpPutRequest("http://192.168.0.145:8080/rest/things/plugwiseha:zone:adam:PW_Woonkamer_zone/enable", "application/json", 'false', headers, 1000)
        sendHttpPutRequest("http://192.168.0.145:8080/rest/things/plugwiseha:zone:adam:PW_Woonkamer_zone/enable", "application/json", 'true', headers, 1000)
    }

    if (statusKantoor.toString != "ONLINE"){
        sendHttpPutRequest("http://192.168.0.145:8080/rest/things/plugwiseha:zone:adam:PW_Kantoor_zone/enable", "application/json", 'false', headers, 1000)
        sendHttpPutRequest("http://192.168.0.145:8080/rest/things/plugwiseha:zone:adam:PW_Kantoor_zone/enable", "application/json", 'true', headers, 1000)
    }

    if (statusVloerverwarming.toString != "ONLINE"){
        sendHttpPutRequest("http://192.168.0.145:8080/rest/things/plugwiseha:appliance_pump:adam:PW_Vloerverwarmingspomp/enable", "application/json", 'false', headers, 1000)
        sendHttpPutRequest("http://192.168.0.145:8080/rest/things/plugwiseha:appliance_pump:adam:PW_Vloerverwarmingspomp/enable", "application/json", 'true', headers, 1000)
    }

    if (statusTom.toString != "ONLINE"){
        sendHttpPutRequest("http://192.168.0.145:8080/rest/things/plugwiseha:appliance_valve:adam:PW_TomWoonkamer/enable", "application/json", 'false', headers, 1000)
        sendHttpPutRequest("http://192.168.0.145:8080/rest/things/plugwiseha:appliance_valve:adam:PW_TomWoonkamer/enable", "application/json", 'true', headers, 1000)
    }

    if (statusKetel.toString != "ONLINE"){
        sendHttpPutRequest("http://192.168.0.145:8080/rest/things/plugwiseha:appliance_boiler:adam:PW_Ketel/enable", "application/json", 'false', headers, 1000)
        sendHttpPutRequest("http://192.168.0.145:8080/rest/things/plugwiseha:appliance_boiler:adam:PW_Ketel/enable", "application/json", 'true', headers, 1000)
    }

I tested it and it’s this part where it goes wrong:

sendHttpPutRequest("http://192.168.0.145:8080/rest/things/plugwiseha:zone:adam:PW_Woonkamer_zone/enable", "application/json", 'false', headers, 1000)

Isn’t it supported anymore in 3.2? Or did i use a flaw in earlier versions? Or is it just a bug in 3.2?

Hope someone knows!

Oliver2 · December 27, 2021, 9:28am

in case you also migrated to OpenJDK I’d try to revert back to Zulu JDK

djpsycho82 · December 27, 2021, 9:35am

I did upgrade Java when it was a choice after upgrade openhab through openhabian-config. Not sure how to revert back to the old version. Do you know how to do it?

(I think didn’t migrate to OpenJDK, just an upgrade to version 11 of Zulu JDK, but i’m not sure)

Wolfgang_S · December 27, 2021, 11:25am

According to the API explorer it has to be “text/plain” instead of “application/json”.

djpsycho82 · December 27, 2021, 1:16pm

This was the sollution. In 3.1 openhab didn’t mind the type, but in 3.2 it did and it should i think.

Thnx for the sollution. Didn’t realise i could look it up in the API explorer. I’m not that good with this type of commands.

Learning every day!

mischmi · December 30, 2021, 5:02pm

Thx a lot Wolfgang !!!
After hours of try & error, I found your hint. With
sendHttpPutRequest(“http://myLogin:myPassword@myIP:8080/rest/things/myThing/enable”, “application/json”, ‘false’)
I could disable ‘myThing’ up to opnHAB Version 3.1.1. Follwing your hint it now agin runs with opernHAB Version 3.2 and 3.3:
sendHttpPutRequest(“http://myLogin:myPassword@myIP:8080/rest/things/myThing/enable”, “text/plain”, ‘false’)
To enable ‘myThing’ again I replaced ‘false’ by ‘true’.

HansWurst · March 3, 2022, 11:12am

Oh wow,

Thanks so much, both of you @mischmi and @Wolfgang_S!

This has really made my day, as I was stuck on this topic for about two months now.

For those who may have a similair problem as I did: I needed this kind of rule, to peridocally disable and reenable a Homematic CCU2 thing. I know it’s a sloppy workaround but that’s what I had been doing manually for weeks, at least now its automated. The problem itself is (partly) described here:

Since the update to OH 3.1, some things discovered by the CCU showed the described config errors, as if the CCU was offline, although it wasn’t. Also some things stopped updating their states reliably and at random times. E.g. A Thermostat would randomly stop reporting the actual temperature and a door/window contact wouldn’t update its state. That’s quite annoying as it “breaks” persistence based rules and proper graphing, of course.

To be fair, in the above thread there is also a solution posted by he developer of the binding, involving manual installation of an not yet official version of the homematic binding, I think. Being relatively inexperienced, I opted for this workaround with the rules, and maybe waiting for an official update of the binding. I realize that updating the binding is the cleaner way but I’m a little afraid to use inofficial versions yet.

I hope it’s ok to post this workaround in this thread too, as I had a pretty hard time getting here (with an awful lot of googling). Maybe someone will find the same solution useful.

Cheers!

kreack · June 19, 2022, 10:23pm

Hi Michael,
after try to run my rule Irecive following messages:

`2022-06-20 00:20:54.023 [WARN ] [ore.io.rest.auth.internal.AuthFilter] - Unauthorized API request: Basic authentication with username/password is not allowed

2022-06-20 00:20:54.029 [ERROR] [enhab.core.model.script.actions.HTTP] - Fatal transport error: java.util.concurrent.ExecutionException: org.eclipse.jetty.client.HttpResponseException: HTTP protocol violation: Authentication challenge without WWW-Authenticate header`

any idea what is wrong?

- openHAB version: openHAB 3.2.0 - Release Build

Thanks & regards, Sergo