I’m looping through my things to do some sanity checks .
For the zwave things I’m looping through the nodes by numbers. Thing = self.openhab.get_thing(ThingName)
But there are some gaps in the list. I would like to avoid to maintain a positive list, which nodes are available and which are not.
Today I’m suppressing the ThingNotFoundError, but the warning [WARN ] [HABApp.openhab.connection] - Status 404 for GET http://192.168.43.2:8080/rest/things/zwave:device:gehirn:node2 is still coming.
I would like to check in advance if thing is existing (like the function for items) or suppress the warning.
Is that possible?
I loop through the node numbers, try to get the information about the associated thing and if it is available, I do some checks. If I add more devices it will handle it automatically.
# alle Devices durchlaufen
for DeviceNumber in range(2, NUMBER_ZWAVE_DEVICES + 1):
ThingName = ZWAVE_THING_PREFIX + str(DeviceNumber)
Thing: OpenhabThingDefinition = None
try:
Thing = self.openhab.get_thing(ThingName)
except ThingNotFoundError:
pass
except Exception as e:
self.log.error(LOGGER + "Error: {}".format(e))
if Thing is not None:
LastWakeUp = self.ThingInfoWakeUp(Thing)
if LastWakeUp is not None:
self.log.error(LOGGER + "Timeout von {} am Standort {} seit {} ".format(Thing.label, Thing.location, LastWakeUp))
# Status-Meldung auswerten
Status = Thing.status.status
if Status != "ONLINE":
...
The result now is:
2022-12-19 19:12:16.493 [WARN ] [HABApp.openhab.connection] - Status 404 for GET http://localhost:8080/rest/things/zwave:device:gehirn:node2
2022-12-19 19:12:16.503 [WARN ] [HABApp.openhab.connection] - Status 404 for GET http://localhost:8080/rest/things/zwave:device:gehirn:node3
2022-12-19 19:12:16.568 [WARN ] [HABApp.openhab.connection] - Status 404 for GET http://localhost:8080/rest/things/zwave:device:gehirn:node8
2022-12-19 19:12:16.589 [WARN ] [HABApp.openhab.connection] - Status 404 for GET http://localhost:8080/rest/things/zwave:device:gehirn:node10
2022-12-19 19:12:16.613 [WARN ] [HABApp.openhab.connection] - Status 404 for GET http://localhost:8080/rest/things/zwave:device:gehirn:node12
2022-12-19 19:12:16.650 [WARN ] [HABApp.openhab.connection] - Status 404 for GET http://localhost:8080/rest/things/zwave:device:gehirn:node15
2022-12-19 19:12:16.685 [WARN ] [HABApp.openhab.connection] - Status 404 for GET http://localhost:8080/rest/things/zwave:device:gehirn:node19
2022-12-19 19:12:16.693 [WARN ] [HABApp.openhab.connection] - Status 404 for GET http://localhost:8080/rest/things/zwave:device:gehirn:node20
2022-12-19 19:12:16.701 [WARN ] [HABApp.openhab.connection] - Status 404 for GET http://localhost:8080/rest/things/zwave:device:gehirn:node21
2022-12-19 19:12:16.710 [WARN ] [HABApp.openhab.connection] - Status 404 for GET http://localhost:8080/rest/things/zwave:device:gehirn:node22
2022-12-19 19:12:16.718 [WARN ] [HABApp.openhab.connection] - Status 404 for GET http://localhost:8080/rest/things/zwave:device:gehirn:node23
2022-12-19 19:12:16.728 [WARN ] [HABApp.openhab.connection] - Status 404 for GET http://localhost:8080/rest/things/zwave:device:gehirn:node24
2022-12-19 19:12:16.737 [WARN ] [HABApp.openhab.connection] - Status 404 for GET http://localhost:8080/rest/things/zwave:device:gehirn:node26
2022-12-19 19:12:16.745 [WARN ] [HABApp.openhab.connection] - Status 404 for GET http://localhost:8080/rest/things/zwave:device:gehirn:node28
2022-12-19 19:12:16.766 [WARN ] [HABApp.openhab.connection] - Status 404 for GET http://localhost:8080/rest/things/zwave:device:gehirn:node30
2022-12-19 19:12:16.787 [WARN ] [HABApp.openhab.connection] - Status 404 for GET http://localhost:8080/rest/things/zwave:device:gehirn:node32
2022-12-19 19:12:16.811 [WARN ] [HABApp.openhab.connection] - Status 404 for GET http://localhost:8080/rest/things/zwave:device:gehirn:node34
2022-12-19 19:12:16.834 [WARN ] [HABApp.openhab.connection] - Status 404 for GET http://localhost:8080/rest/things/zwave:device:gehirn:node39
2022-12-19 19:12:16.842 [WARN ] [HABApp.openhab.connection] - Status 404 for GET http://localhost:8080/rest/things/zwave:device:gehirn:node41
2022-12-19 19:12:16.940 [WARN ] [HABApp.openhab.connection] - Status 404 for GET http://localhost:8080/rest/things/zwave:device:gehirn:node51
2022-12-19 19:12:16.959 [ERROR] [HABApp ] - System_Things.CheckZWaveThings Timeout von Türsensor Garage am Standort Garage seit 2022-12-19 18:08:50
2022-12-19 19:12:16.978 [ERROR] [HABApp ] - System_Things.CheckZWaveThings Timeout von Türsensor Wintergarten am Standort Wintergarten seit 2022-12-19 18:06:51
2022-12-19 19:12:16.988 [WARN ] [HABApp.openhab.connection] - Status 404 for GET http://localhost:8080/rest/things/zwave:device:gehirn:node54
2022-12-19 19:12:16.997 [WARN ] [HABApp.openhab.connection] - Status 404 for GET http://localhost:8080/rest/things/zwave:device:gehirn:node55
2022-12-19 19:12:17.005 [WARN ] [HABApp.openhab.connection] - Status 404 for GET http://localhost:8080/rest/things/zwave:device:gehirn:node56
2022-12-19 19:12:17.014 [WARN ] [HABApp.openhab.connection] - Status 404 for GET http://localhost:8080/rest/things/zwave:device:gehirn:node57
2022-12-19 19:12:17.022 [WARN ] [HABApp.openhab.connection] - Status 404 for GET http://localhost:8080/rest/things/zwave:device:gehirn:node58
2022-12-19 19:12:17.035 [ERROR] [HABApp ] - System_Things.CheckZWaveThings ThingStatus: Node: zwave:device:gehirn:node59 (Fensterkontakt Badezimmer): UNINITIALIZED - DISABLED
2022-12-19 19:12:17.064 [ERROR] [HABApp ] - System_Things.CheckZWaveThings Timeout von Fenstersensor Badezimmer am Standort Badezimmer seit 2022-12-19 18:10:39
Wouldn’t it be enough to e.g. use the REST API to download the list of things ? It already contains the information if a thing is online or offline. I would assume that HABApp provides its own call to do the same. I do not expect that you will detect more items missing than those being shown offline in the REST API:
Hi, that’s a cool approach, I haven’t thought about.
But I have two problems with it:
The data is incomplete. I’m missing the location and in a slightly different use case also the status description.
It seems that the data is updated only on startup. There is a property “zwave_lastwakeup” I’m looking for. This information is outdated when I use your approach. When fetching the data from REST (via get_thing) the information is current.
Checking the property “zwave_lastwakeup” is the main purpose of my code.
Now I did a combination of both approaches. Use the ThingItem to get the valid things and use the get_thing() function to fetch the data.
Can you create an issue on github an show the data that is missing and what you are doing with it?
I’ve never seen anything useful in the status description, only in the status detail.
I remember I haven’t subscribed to the event.
I’ll try things out and add this to the next release.
Thanks for the hint to change the topic filter in the config.yml to openhab/things/*instead of openhab/things/*/added,openhab/things/*/removed,openhab/things/*/status,openhab/things/*/statuschanged
That worked and has enabled me to change my concept completely.
I think I’ll make this the default in one of the upcoming releases.
I wanted to do some more tests so I can be sure everything works as desired but haven’t had time yet.
Maybe you can report back in a couple of days in the issue and give me a heads up if everything still works?