2017-02-06 07:09:46.145 [ERROR] [.binding.avmfritz.handler.BoxHandler] -
java.lang.NullPointerException
at org.openhab.binding.avmfritz.handler.BoxHandler.updateThingFromDevice(BoxHandler.java:203)[12:org.openhab.binding.avmfritz:2.1.0.201702051325]
at org.openhab.binding.avmfritz.handler.BoxHandler.addDeviceList(BoxHandler.java:137)[12:org.openhab.binding.avmfritz:2.1.0.201702051325]
at org.openhab.binding.avmfritz.internal.hardware.callbacks.FritzAhaUpdateXmlCallback.execute(FritzAhaUpdateXmlCallback.java:70)[12:org.openhab.binding.avmfritz:2.1.0.201702051325]
at org.openhab.binding.avmfritz.internal.hardware.FritzahaContentExchange.onComplete(FritzahaContentExchange.java:71)[12:org.openhab.binding.avmfritz:2.1.0.201702051325]
at org.eclipse.jetty.client.ResponseNotifier.notifyComplete(ResponseNotifier.java:193)[73:org.eclipse.jetty.client:9.2.19.v20160908]
at org.eclipse.jetty.client.ResponseNotifier.notifyComplete(ResponseNotifier.java:185)[73:org.eclipse.jetty.client:9.2.19.v20160908]
at org.eclipse.jetty.client.HttpReceiver.terminateResponse(HttpReceiver.java:453)[73:org.eclipse.jetty.client:9.2.19.v20160908]
at org.eclipse.jetty.client.HttpReceiver.responseSuccess(HttpReceiver.java:400)[73:org.eclipse.jetty.client:9.2.19.v20160908]
at org.eclipse.jetty.client.http.HttpReceiverOverHTTP.messageComplete(HttpReceiverOverHTTP.java:266)[73:org.eclipse.jetty.client:9.2.19.v20160908]
at org.eclipse.jetty.http.HttpParser.parseContent(HttpParser.java:1487)[75:org.eclipse.jetty.http:9.2.19.v20160908]
at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:1245)[75:org.eclipse.jetty.http:9.2.19.v20160908]
at org.eclipse.jetty.client.http.HttpReceiverOverHTTP.parse(HttpReceiverOverHTTP.java:156)[73:org.eclipse.jetty.client:9.2.19.v20160908]
at org.eclipse.jetty.client.http.HttpReceiverOverHTTP.process(HttpReceiverOverHTTP.java:117)[73:org.eclipse.jetty.client:9.2.19.v20160908]
at org.eclipse.jetty.client.http.HttpReceiverOverHTTP.receive(HttpReceiverOverHTTP.java:69)[73:org.eclipse.jetty.client:9.2.19.v20160908]
at org.eclipse.jetty.client.http.HttpChannelOverHTTP.receive(HttpChannelOverHTTP.java:89)[73:org.eclipse.jetty.client:9.2.19.v20160908]
at org.eclipse.jetty.client.http.HttpConnectionOverHTTP.onFillable(HttpConnectionOverHTTP.java:123)[73:org.eclipse.jetty.client:9.2.19.v20160908]
at org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:544)[76:org.eclipse.jetty.io:9.2.19.v20160908]
at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:635)[87:org.eclipse.jetty.util:9.2.19.v20160908]
at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:555)[87:org.eclipse.jetty.util:9.2.19.v20160908]
at java.lang.Thread.run(Thread.java:745)[:1.8.0_121]
2017-02-06 07:09:46.320 [ERROR] [.binding.avmfritz.handler.BoxHandler] -
java.lang.NullPointerException
at org.openhab.binding.avmfritz.handler.BoxHandler.updateThingFromDevice(BoxHandler.java:203)[12:org.openhab.binding.avmfritz:2.1.0.201702051325]
at org.openhab.binding.avmfritz.handler.BoxHandler.addDeviceList(BoxHandler.java:137)[12:org.openhab.binding.avmfritz:2.1.0.201702051325]
at org.openhab.binding.avmfritz.internal.hardware.callbacks.FritzAhaUpdateXmlCallback.execute(FritzAhaUpdateXmlCallback.java:70)[12:org.openhab.binding.avmfritz:2.1.0.201702051325]
at org.openhab.binding.avmfritz.internal.hardware.FritzahaContentExchange.onComplete(FritzahaContentExchange.java:71)[12:org.openhab.binding.avmfritz:2.1.0.201702051325]
at org.eclipse.jetty.client.ResponseNotifier.notifyComplete(ResponseNotifier.java:193)[73:org.eclipse.jetty.client:9.2.19.v20160908]
at org.eclipse.jetty.client.ResponseNotifier.notifyComplete(ResponseNotifier.java:185)[73:org.eclipse.jetty.client:9.2.19.v20160908]
at org.eclipse.jetty.client.HttpReceiver.terminateResponse(HttpReceiver.java:453)[73:org.eclipse.jetty.client:9.2.19.v20160908]
at org.eclipse.jetty.client.HttpReceiver.responseSuccess(HttpReceiver.java:400)[73:org.eclipse.jetty.client:9.2.19.v20160908]
at org.eclipse.jetty.client.http.HttpReceiverOverHTTP.messageComplete(HttpReceiverOverHTTP.java:266)[73:org.eclipse.jetty.client:9.2.19.v20160908]
at org.eclipse.jetty.http.HttpParser.parseContent(HttpParser.java:1487)[75:org.eclipse.jetty.http:9.2.19.v20160908]
at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:1245)[75:org.eclipse.jetty.http:9.2.19.v20160908]
at org.eclipse.jetty.client.http.HttpReceiverOverHTTP.parse(HttpReceiverOverHTTP.java:156)[73:org.eclipse.jetty.client:9.2.19.v20160908]
at org.eclipse.jetty.client.http.HttpReceiverOverHTTP.process(HttpReceiverOverHTTP.java:117)[73:org.eclipse.jetty.client:9.2.19.v20160908]
at org.eclipse.jetty.client.http.HttpReceiverOverHTTP.receive(HttpReceiverOverHTTP.java:69)[73:org.eclipse.jetty.client:9.2.19.v20160908]
at org.eclipse.jetty.client.http.HttpChannelOverHTTP.receive(HttpChannelOverHTTP.java:89)[73:org.eclipse.jetty.client:9.2.19.v20160908]
at org.eclipse.jetty.client.http.HttpConnectionOverHTTP.onFillable(HttpConnectionOverHTTP.java:123)[73:org.eclipse.jetty.client:9.2.19.v20160908]
at org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:544)[76:org.eclipse.jetty.io:9.2.19.v20160908]
at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:635)[87:org.eclipse.jetty.util:9.2.19.v20160908]
at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:555)[87:org.eclipse.jetty.util:9.2.19.v20160908]
at java.lang.Thread.run(Thread.java:745)[:1.8.0_121]
just to get an overview of your setting. Can you specify a little more about it? That would be nice: Which version of the avmfritz binding do you use? Did you install it over Paper UI, apt-sources or an other way?
Please keep in mind that the Comet DECT implementation is not merged to the main repository, yet.
Unfortunately, nobody could help me with that issue: https://community.openhab.org/t/how-to-get-oha2-to-install-jar-files-in-addons-folder/24538/5.
Therefore, I have to presume that replacing bindings from repo with packages from addons-Folder is instable. With openhabian it works, with a manual install not… So I can not replace avmfritz binding’s repo version with the version from here.
Because of this issue - may I kindly ask when the avmfritz binding version supporting Comet Dect will be merged to the SNAPSHOT repository?
I am sorry that I cannot help you to solve your problem. I can understand that you do not want to use experimental versions and tinker around in your setup.
I hope my PR #1815 will be merged shortly. But we have to wait until one of the maintainers maybe @Kai himself will review it and confirm to merge it.
I do not mind using experimental versions like SNAPSHOT builds - that’s why I would like to have this extended binding version merged into this branch … And I do not mind either tinkering around in my setup as long as I can come to a positive result or gain the knowledge why I definitely can not. But in this case, I do not have a single indication why not, i. e. why not in the case of manual installation (which is definitely easier to maintain)!
I can acknowledge that this binding extension works very well and moreover, it’s a real improvement - therefore, I wonder why it does not become integrated in SNAPSHOT version of OHA2. I thought that is where SNAPSHOT builds are for ;).
Thank you for the link to your PR! Now I can have an eye on the progress myself and I will now be able to know very soon when the big moment has come. No need to install new SNAPSHOT any longer and being disappointed again about still not integrated this great one…
I’m also still waiting for Comet DECT support. In my first openHAB installation on Windows I used OH 1.8 - there It was working - at least I could read out the temperature. But after a short time I started to build a productive RasPi with openHABian 2.0 - where this is not possible.
I am sorry to hear, but maybe you are right. Could you check if the temperature channel works for you? It should provide the same values like the ‘actual_temp’ channel. I am going to proof the code.
Number COMETDECTActualTempCD1 "Raumtemperatur [%.1f °C]" {
channel="avmfritz:Comet_DECT:192_1XX_XXX_XXX:10971xxxxxxx:temperature"
}
@cweitkamp I don’t know if it a general binding question or a question related to the Comet DECT. I want to create a simple two state time plan for my heating. I have set up the following items
If I switch the Livingroom_Heating_1_RadiatorMode from Comfort to ECO it changes the temperature in the device to 15.5 °C, which I initially set like this in the Fritzbox, but I can not change the temperature it changes to via the binding. I thought I could do this by changing Livingroom_Heating_1_Eco / Comf via e.g.
Livingroom_Heating_1_EcoTemp.sendCommand(16)
It changes the value for 1ms but than gets resetted to the initial FritzBox value (15.5°C) again
2021-10-22 09:35:35.084 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Livingroom_Heating_1_EcoTemp' changed from 15.5 °C to 16 °C
2021-10-22 09:35:41.388 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Livingroom_Heating_1_EcoTemp' changed from 16 °C to 15.5 °C
For Comfort it even doesnt change the temperature at all
2021-10-22 09:57:59.174 [INFO ] [openhab.event.ItemCommandEvent ] - Item 'Livingroom_Heating_1_ComfTemp' received command 20.5
2021-10-22 09:57:59.192 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'Livingroom_Heating_1_ComfTemp' predicted to become NULL
Does not change the behaviour, it gets automatically resetted to value set in FritzBox Settings
Livingroom_Heating_1_EcoTemp.sendCommand(13|"°C")
2021-10-22 14:39:18.808 [INFO ] [openhab.event.ItemCommandEvent ] - Item 'Livingroom_Heating_1_EcoTemp' received command 13 °C
2021-10-22 14:39:18.828 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'Livingroom_Heating_1_EcoTemp' predicted to become 13 °C
2021-10-22 14:39:18.853 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Livingroom_Heating_1_EcoTemp' changed from 15.5 °C to 13 °C
2021-10-22 14:39:30.080 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Livingroom_Heating_1_EcoTemp' changed from 13 °C to 15.5 °C
Looks like the command isn’t actioned at all. (the change/revert state change is just about ‘autoupdate’ guessing, followed by the device saying “nope, it’s like this”)
A slightly less ancient thread that looks more relevant -