Repository: openhab/openhab-addons

Issue #9771: [avmfritz] DECT Thermostat Handler crashes after being changed by external call (calendar event in my case) causing the state to be lost
Created: 2021-01-10T16:07:50Z
After migration to OH3 I am experiencing a NULL poniter  exception in ThingHandler.handleCommand() after the set value is changed by an external rule/event (icalendar in my case). Using The UI changing the set value for the DECT thermostat works without any issues.
Part of the log showing the behavior:
2021-01-10 16:45:43.239 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'Thermostat_OG_Bad' received command 21
2021-01-10 16:45:43.260 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'Thermostat_OG_Bad' predicted to become 21
2021-01-10 16:45:43.282 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Thermostat_OG_Bad' changed from 20.0 to 21
2021-01-10 16:45:43.305 [ERROR] [nal.common.AbstractInvocationHandler] - An error occurred while calling method 'ThingHandler.handleCommand()' on 'org.openhab.binding.avmfritz.internal.handler.AVMFritzHeatingDeviceHandler@cc08da': null
2021-01-10 16:45:43.905 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Thermostat_OG_Bad' changed from 21 to 20.0
Full Stacktrace:
[ERROR] [nal.common.AbstractInvocationHandler] - An error occurred while calling method 'ThingHandler.handleCommand()' on 'org.openhab.binding.avmfritz.internal.handler.AVMFritzHeatingDeviceHandler@cc08da': null
java.lang.NullPointerException: null
at org.openhab.binding.avmfritz.internal.handler.AVMFritzBaseThingHandler.handleCommand(AVMFritzBaseThingHandler.java:348) ~[?:?]
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:?]
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[?:?]
at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:?]
at java.lang.reflect.Method.invoke(Method.java:566) ~[?:?]
at org.openhab.core.internal.common.AbstractInvocationHandler.invokeDirect(AbstractInvocationHandler.java:154) [bundleFile:?]
at org.openhab.core.internal.common.InvocationHandlerSync.invoke(InvocationHandlerSync.java:59) [bundleFile:?]
at com.sun.proxy.$Proxy299.handleCommand(Unknown Source) [?:?]
at org.openhab.core.thing.internal.profiles.ProfileCallbackImpl.handleCommand(ProfileCallbackImpl.java:80) [bundleFile:?]
at org.openhab.core.thing.internal.profiles.SystemDefaultProfile.onCommandFromItem(SystemDefaultProfile.java:48) [bundleFile:?]
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:?]
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[?:?]
at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:?]
at java.lang.reflect.Method.invoke(Method.java:566) ~[?:?]
at org.openhab.core.internal.common.AbstractInvocationHandler.invokeDirect(AbstractInvocationHandler.java:154) [bundleFile:?]
at org.openhab.core.internal.common.Invocation.call(Invocation.java:52) [bundleFile:?]
at java.util.concurrent.FutureTask.run(FutureTask.java:264) [?:?]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) [?:?]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) [?:?]
at java.lang.Thread.run(Thread.java:834) [?:?]
Expected Behavior
New set point (21°C in my case) should be set until changed manually or by an external trigger.
Current Behavior
Current state of the set point is lost and previous state is restored .
Possible Solution
Not yet - have to track the NULL pointer...
Steps to Reproduce (for Bugs)

In Generate a calendar event to set the termostat's set value: "BEGIN:Thermostat_OG_Bad:21\nEND:Thermostat_OG_Bad:16"
Wait for the calendar event to trigger and check the logs.

Context
see initial description. Heating-Set-Points based on iCalendar.
Your Environment

Version used: openHAB 3.0.0, AVM FRITZ!Box Binding 3.0.0,iCalendar Binding 3.0.0
FRITZ!Box 6590 Cable w. FritzOS 07.20, Comet DECT Thermostats (FW 03.54)
Operating System and version (desktop or mobile, Windows 10, Raspbian Buster, ...): openHABianPi 4.19.66-v7+

Duplicate issue #9820: [icalendar] Wrong Command type will be used
Created: 2021-01-14T08:10:18Z
Expected Behavior
I want to setup a rule via ical that changes the mode of my Z-Wave device (Spirit Thermostatic Valve).
For this I have to send the mode 1 (= comfort mode) or 11 (= eco mode) to the device.
I would expect that setting up a calendar entry with these values 1 or 11 will change the mode of the device. But it doesn't.
Current Behavior
I setup a rule in my calendar, but the device doesn't change the mode.
I changed the log-level to TRACE and was able to see that the command will be send to the device as a QuantityType even though I just defined the item as a Number (without an extra unit of measurement).
Meaning that I can see the rule is triggered and also uses the right value. In the openHAB app I also see the mode changes, but on the device itself nothing was done.
icalendar binding log:
2021-01-14 06:39:03.630 [TRACE] [.icalendar.internal.logic.CommandTag] - Command Tag Trace: "END:OG_Bad_Heizung_Radiator_Mode:11" => Fully valid Command Tag!
2021-01-14 06:39:03.642 [DEBUG] [ar.internal.handler.ICalendarHandler] - Event: [OG Bad] Heizung aktiv, Command Tag: BEGIN:OG_Bad_Heizung_Radiator_Mode:1 => OG_Bad_Heizung_Radiator_Mode.postUpdate(QuantityType: 1)

event log:
2021-01-14 06:39:03.715 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'OG_Bad_Heizung_Radiator_Mode' received command 1
2021-01-14 06:39:03.733 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'OG_Bad_Heizung_Radiator_Mode' predicted to become 1
2021-01-14 06:39:03.745 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'OG_Bad_Heizung_Radiator_Mode' changed from 11 to 1

z-wave log:
2021-01-14 06:39:03.733 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 63: Command received zwave:device:controller:node63:thermostat_mode --> 1 [QuantityType]
2021-01-14 06:39:03.733 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 63: Command for unknown channel zwave:device:controller:node63:thermostat_mode with QuantityType

Calendar event description:
BEGIN:OG_Bad_Heizung_Radiator_Mode:1
END:OG_Bad_Heizung_Radiator_Mode:11

As you can see always the QuantityType will be used, but I would expect a DecimalType.
When I trigger a change via app I can see a DecimalType will be send to the device. So this is the only difference I was able to find that could lead to the issue that the device itself doesn't change.
I am unsure if the z-wave binding should be capable of resolving a QuantityType to a DecimalType if required or not.
The strange thing is that I tried to reproduce this issue using JSR223 (Python) integration and trigger sendCommand with a QuantityType ... when I am doing this I could see QuantityType will be used for sendCommand, but in the z-wave logs I see a DecimalType will be used. So maybe there is already some kind of auto-conversion that will not be used within the icalendar binding.
Possible Solution
Solution 1:
Enhance the CommandTag. In case the resolved QuantityType has a unit of ONE convert it to a DecimalType.
Solution 2:
Before sending the event to the item in ICalendarHandler check if the Number item has a unit-of-measurement. If not convert the QuantityType to a DecimalType.
Solution 3:
Do the conversion somewhere else, maybe outside of this binding at all?
Solution 4:
...?
Steps to Reproduce (for Bugs)

Setup a Number item
Setup a calendar entry sending a number to this item
Check the Command type that will be send to this item

Context
Changing my z-wave thermostatic valve mode via calendar entries.
Your Environment

Version used: openHAB + icalendar binding v3.0.0
Operating System and version: raspbian on raspberry pi4 + razberry as z-wave module

Closing comment (2021-01-16T07:53:14Z): Hi there, this looks similar to #9771 but the other way around. As described in #9771 (comment) I am wondering why DecimalType is missing in the list of possible commands. We have to ask @daMihe for the reason.

  
    
      openhab-addons/bundles/org.openhab.binding.icalendar/src/main/java/org/openhab/binding/icalendar/internal/logic/CommandTag.java
    
    
        Lines 48 to 50
      in
      b6eea71
    
  
  
    

        
          
           private static final List<Class<? extends Command>> otherCommandTypes = Arrays.asList(QuantityType.class, 
        

        
          
                   OnOffType.class, OpenClosedType.class, UpDownType.class, HSBType.class, PlayPauseType.class, 
        

        
          
                   RewindFastforwardType.class, StringType.class); 
        
    
  



icalendar binding: The given command line in the calendar events will be parsed according to the above ordered list. Meaning QuantityType will be checked first. This seems to succeed but without a proper unit (One will be used instead, if you do not define something). I am wondering why DecimalType is missing in this list.