What am I experiencing? 'Item' changed from NULL to UNDEF

Setup, Configuration and Use Items & Sitemaps
1
  • Platform information:
    runtimeInfo:
    version: 3.4.2
    buildString: Release Build
    locale: en-US
    systemInfo:
    configFolder: /etc/openhab
    userdataFolder: /var/lib/openhab
    logFolder: /var/log/openhab
    javaVersion: 11.0.13
    javaVendor: Azul Systems, Inc.
    javaVendorVersion: Zulu11.52+13-CA
    osName: Linux
    osVersion: 5.10.103-v7l+
    osArchitecture: arm
    availableProcessors: 4
    freeMemory: 80018624
    totalMemory: 259522560
    startLevel: 100
    bindings:
    • airquality
    • amazonechocontrol
    • astro
    • denonmarantz
    • ecobee
    • exec
    • feed
    • gpio
    • http
    • hue
    • icalendar
    • icloud
    • irobot
    • lgwebos
    • logreader
    • mqtt
    • myq
    • network
    • networkupstools
    • snmp
    • sonos
    • speedtest
    • systeminfo
    • unifi
    • unifiprotect
    • weathercompany
    • wled
    • zoneminder
      clientInfo:
      device:
      ios: false
      android: false
      androidChrome: false
      desktop: true
      iphone: false
      ipod: false
      ipad: false
      edge: false
      ie: false
      firefox: false
      macos: true
      windows: false
      cordova: false
      phonegap: false
      electron: false
      nwjs: false
      webView: false
      webview: false
      standalone: false
      os: macos
      pixelRatio: 2
      prefersColorScheme: dark
      isSecureContext: false
      locationbarVisible: true
      menubarVisible: true
      navigator:
      cookieEnabled: true
      deviceMemory: N/A
      hardwareConcurrency: 8
      language: en-US
      languages:
      • en-US
        onLine: true
        platform: MacIntel
        screen:
        width: 1496
        height: 967
        colorDepth: 24
        support:
        touch: false
        pointerEvents: true
        observer: true
        passiveListener: true
        gestures: false
        intersectionObserver: true
        themeOptions:
        dark: dark
        filled: true
        pageTransitionAnimation: default
        bars: light
        homeNavbar: default
        homeBackground: default
        expandableCardAnimation: default
        userAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15
        (KHTML, like Gecko) Version/16.2 Safari/605.1.15
        timestamp: 2023-04-12T01:20:34.433Z

I have about 30 items showing a status of UNDEF. I can look at one in the logs after a reboot and see it changed from NULL to UNDEF.

2023-04-11 21:06:37.335 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Sensor_OutdoorDriveway_Temperature' changed from NULL to UNDEF

However, if I go to the thing, and create a new test item and link it to the same channel as the UNDEF item above, it happily gets a value:

2023-04-11 21:06:05.604 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'TEST_temperature' changed from NULL to 67.37 °F
2023-04-11 21:07:02.789 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'TEST_temperature' changed from 67.37 °F to 66.866 °F
2023-04-11 21:12:02.236 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'TEST_temperature' changed from 66.866 °F to 66.614 °F

It may have started in mid-march with 3.4.2? This is a very busy time for me and we’ve had construction going on so I haven’t paid as much attention as I’d have liked… and sadly don’t have as much time to troubleshoot as I’d like, but the wife just complained about a rule not running and the device showed UNDEF…

image
image1476×402 37.6 KB

2

What binding? Some bindings will update Items to UNDEF when they lose connectivity to the device (or the bridge). That’s usually frowned upon so that’s not common behavior.

More usually an Item changes to UNDEF because you have a rule that changes it to that or there is an Expire configured on the Item to change it to that when the Item doesn’t update or change for too long.

3

Rich - thank you kindly for your reply (and all of your support of these forums!).

The thing is, it is a mix of bindings - unifi, icalendar, systeminfo, hue, ecobee, and others… and the things are online and reporting results in other channels.

I don’t use the expire binding. I have a script that uses the API to populate a database with item info for easy seaching/sorting/etc.

But the weird behavior is that if I link a second item to the same channel, it gets a valid value while the previously-created item remains UNDEF. See above, and below (just created this one).

image
image1438×406 41.7 KB

A couple more tests:
I can use info from the database to delete and recreate the item and it works as well.
However:
If I remove the link, but not the item, and then re-link it to the same channel I get UNDEF.

4

There is no binding in OH 3. It’s part of core.

All I can recommend is to put the binding into debug logging and see what they are doing.

5

I’m just going to delete all the UNDEF items and re-create.

I did it with one, using the API to check the item definition and link and they are basically identical except for metadata.

All these items stopped responding on the same day (unless they were an obsolete item) so something happened somewhere. I feel like it would be helpful to know why but don’t have time to dig in much further. I don’t think it is an issue with any specific binding as creating a new item instantly delivers a value to the item.

item:
{
“link”: “http://pi-openhab:8080/rest/items/Sensor_Barn_Temperature”,
“state”: “UNDEF”,
“stateDescription”: {
“pattern”: “%.1f° F”,
“readOnly”: true,
“options”: []
},
“editable”: true,
“type”: “Number:Temperature”,
“name”: “Sensor_Barn_Temperature”,
“label”: “Sensor_Barn_Temperature”,
“category”: “temperature”,
“tags”: [],
“groupNames”: [
“gMet_Temperature”
]
}

link:
{
“editable”: true,
“channelUID”: “ecobee:thermostat:fe3e2fSDASD8:5226671ASDASD082:runtime#actualTemperature”,
“configuration”: {},
“itemName”: “Sensor_Barn_Temperature”
}

recreate by adding new item through text configuration in UI:

Number:Temperature Sensor_Barn_Temperature “Sensor_Barn_Temperature” (gMet_Temperature) {channel=“ecobee:thermostat:fe3eXXXbc8:522XX719XXXX:runtime#actualTemperature”}

item:
{
“link”: “http://pi-openhab:8080/rest/items/Sensor_Barn_Temperature”,
“state”: “69.1 °F”,
“stateDescription”: {
“pattern”: “%.1f %unit%”,
“readOnly”: true,
“options”: []
},
“editable”: true,
“type”: “Number:Temperature”,
“name”: “Sensor_Barn_Temperature”,
“label”: “Sensor_Barn_Temperature”,
“category”: “temperature”,
“tags”: [],
“groupNames”: [
“gMet_Temperature”
]
}

link:
{
“editable”: true,
“channelUID”: “ecobee:thermostat:fe3e2f3XXXX:26S19XXXX:runtime#actualTemperature”,
“configuration”: {},
“itemName”: “Sensor_Barn_Temperature”
}

6

Perhaps not but you’ve eliminated rules and expire as potential sources of the UNDEF. So that leaves bindings or something truly external changing the Item through the REST API. Nothing else can update and Item to UNDEF (UIs can only send commands and UNDEF cannot be sent as a command). Without further evidence to the contrary, the binding has to be involved somehow.

7

here are the items’ channels, and the number of items in total that that binding supports.
some might be valid…that the item may be obsolete or not have any data in the calendar, but I’m not sure if they should be NULL or UNDEF in that case…perhaps depends on persistence.

channel=“ecobee:sensor:aa3e2f3bc8:511849552556:rs-100:temperature”}
channel=“ecobee:thermostat:aa3e2f3bc8:411921003339:runtime#actualTemperature”}
channel=“ecobee:thermostat:aa3e2f3bc8:411929753564:runtime#actualTemperature”}
channel=“ecobee:thermostat:aa3e2f3bc8:411945952402:runtime#actualTemperature”}
channel=“ecobee:thermostat:aa3e2f3bc8:511849552556:runtime#actualTemperature”}
channel=“ecobee:thermostat:aa3e2f3bc8:522667198082:runtime#actualTemperature”}
channel=“hue:0302:001788468288:124:temperature”}
channel=“hue:0302:001788468288:58:temperature”}
channel=“hue:0302:001788468288:73:temperature”}
channel=“icalendar:eventfilter:1056aae299:Calendar_Away:result_0#begin”}
channel=“icalendar:eventfilter:1056aae299:Calendar_Away:result_0#end”}
channel=“icalendar:eventfilter:1056aae299:NoSchool:result_0#begin”}
channel=“icalendar:eventfilter:1056aae299:NoSchool:result_0#end”}
channel=“icalendar:eventfilter:1056aae299:Xavier_Away:result_0#begin”}
channel=“icalendar:eventfilter:1056aae299:Xavier_Away:result_0#end”}
channel=“icalendar:eventfilter:a015ba6978:VacationEventFilter:result_0#begin”}
channel=“icalendar:eventfilter:a015ba6978:VacationEventFilter:result_0#end”}
channel=“icalendar:eventfilter:a015ba6978:VacationEventFilter:result_0#title”}
channel=“icalendar:eventfilter:BarnInUse:result_0#begin”}
channel=“icalendar:eventfilter:BarnInUse:result_0#end”}
channel=“networkupstools:ups:cde0a126fb:upsRealpower”}
channel=“systeminfo:computer:34c64e24fb:process#load”}
channel=“unifi:wirelessClient:fabc396643:TasmotaSlitintoMobileF790:ap”}
channel=“unifi:wirelessClient:fabc396643:UnifiDafangWyzeFixed1:ap”}
channel=“unifi:wirelessClient:fabc396643:UnifiDafangWyzeFixed2:ap”}
channel=“unifi:wirelessClient:fabc396643:UnifiDafangWyzePTZ1:ap”}
channel=“unifi:wirelessClient:fabc396643:UnifiDafangWyzePTZ2:ap”}
channel=“unifi:wirelessClient:fabc396643:UnifiTasmotaCloudFreeOutlet1:ap”}
channel=“unifi:wirelessClient:fabc396643:UnifiTasmotaNodeMCUBasement:ap”}
channel=“unifi:wirelessClient:fabc396643:UnifiTasmotaNodeMCUXavierDesk:ap”}
channel=“unifi:wirelessClient:fabc396643:UnifiTasmotaSP501eBarnStairs:ap”}
channel=“unifi:wirelessClient:fabc396643:UnifiTasmotaTreatLiaaDimmerNanaStudy:ap”}

ecobee: 25 items
hue: 109 items
networkupstools: 6 items
unifi: 223 items

8

Persistence never saves UNDEF nor NULL states. When an Item is first created/loaded it comes up as NULL and if there is restoreOnStartup configured and there is data to restore, Persistence will update the Item to that. Persistence never does anything with UNDEF.

I could see a binding choosing to set an Item to UNDEF in that case though NULL would be more appropriate. UNDEF is supposed to mean we don’t know what state the Item is, NULL means we do know the state, and it’s uninitialized. A subtle but important distinction. If the data is obsolete than the binding does know the Item should be NULL.

9

Whatever the issue is, deleting and recreating the item and corresponding link immediately fixes the problem for that item. Inspected before and after, the API returns virtually the exact same item definition for the new item as the old item and links.