Error: generic_device.lua:67: attempt to index a nil value [Solved]

[Doler]

In my case it has to do with zigbee2mqtt plugin updates. As far as I can see stas-demydiuk is moving the plugin from version 3.0 to version 3.1. As soon as I update the plugin to it latest commit, a number of additional devices appear along with the above mentioned errors. I moved back (full domoticz directory backup) and things are normal again. Don't know which commit of the plugin is still ok. I am currently on the commit of August 23 and is ok, later commits produce the erroneous situation.

Mark

[EddyG]

The change from 3.0.1 to 3.1 is a big change. The change from importing Domoticz to importing DomoticzEx in plugin.py etc.
That change is used to get over the limit of 255 devices in the zigbee2mqtt plugin.
I tested the new version on a test Raspberry Pi but was not satisfied with the result, so I stick to the 'old' version in my production environment.

[rrozema]

dannybloe will have a look at an actual fix so that the logged message will be accompanied with the actual data causing the problem again (the 1st alternative i tried but failed to get working). dannybloe is however on holidays at them moment and will not have an opportunity to look at it before oktober. Don't hold your breath for it, but a fix is coming.

For your info: an error message will still be logged after the fix is applied. The fix will only make that the logged message will be informative again on for which device and what values a problem was detected. This bug occurs when a problem is detected in one of your devices, making that it can't be properly handled in dzVents because the device doesn't have a valid lastUpdate value. The reason for that missing lastUpdate value still needs more investigation and may even have multiple, different reasons for different devices. As Doler already pointed out, one possible cause for the devices not having a valid lastUpdate value could be in the zigbee2mqtt plugin.

[claude2666]

Same here. It started after update of the zigbee2mqtt plugin v 3.10.
Went back to the previous version, and no more errors.

[waltervl]

Did someone report this on the zigbee2mqtt issue list? Seems that it doing wrong with device updates (but could also relate to Python DomoticzEx).

[rrozema]

Not me

[fvdp80]

Did someone report this on the zigbee2mqtt issue list? Seems that it doing wrong with device updates (but could also relate to Python DomoticzEx).

I just did.

[EddyG]

I still use the 'old' zigbee2mqtt plugin and I have the same issue. Specially at the start of Domoticz and/or the (re)start of zigbee2mqtt service.

[rrozema]

I think I've found the proper fix to make the error message in generic_device.lua correctly show information on the failing device. I've removed the extra name that I had put in earlier, so the change from the original code is smallest (I just replaced the ._ .str from the original code with .toStr):

Code: Select all

		if (data.lastUpdate == '' or data.lastUpdate == nil) then
			local level
			if (data.name ~= nil and data.name ~= '') then
				level = utils.LOG_ERROR
			else
				level = utils.LOG_DEBUG
			end
			if data.baseType ~= 'camera' and data.baseType ~= 'hardware' then
				utils.log('Discarding device. No last update info found: ' .. domoticz.utils.toStr(data), level)
			end
			return nil
		end

[PA3FAT]

having same errors sporadically. Edited the generic_device.lua as advised. Will follow the thread.

[EddyG]

@rrozema Tnx, for that update of the code piece.

I wonder what the reason might be that a device has no lastUpdate or that lastUpdate is set to "", nill or empty by whatever function or hardware.

[rrozema]

Most likely because the 'hardware' in Domoticz has a minor bug in it: It seems to be something specific for some types of 'hardware' only. Either the 'hardware' doesn't properly initialise a newly created device, which could explain the report of 'Dummy' devices triggering the message just after they have been created but no more after they have been triggered at least once. And from the responses I see in this thread I think the new zigbee2mqtt plugin doesn't properly set the lastUpdate property at all on the devices under its control.

[EddyG]

I am still using the 'old' zigbee2mqtt plugin and have the same issue.

[rrozema]

Ok, so the old zigbee2mqtt may already have the same problem. I'm not claiming to know what causes it or to know which hardwares have it and which don't. I haven't checked any sources to verify the issues, I'm just guessing what it could be from the messages sent in this thread.

[EddyG]

I think I know why I get all those error messages about 'lastUpdate'.
When ever I have to stop/start Domoticz (crash or update) the zigbee2mqtt plugin Thread states ended abnormally.
I have to stop Domoticz, disable Zigbee2mqtt plugin (hardware) directly in the database and start Domoticz again.
When Domoticz has started enable the zigbee2mqtt plugin and restart zigbee2mqtt.
It looks to me that all those zigbee device start with NO 'lastUpdate' hence the error when ever a dzVents access such a device.
BUT I checked in the database and ALL zigbee devices have 'lastUpdate' properly filled.
This the kind of error that is logged at almost every first access to a zigbee device.
The only field that is not filled is 'lastUpdate', but it is filled in the database.
Anybody any idea

Code: Select all

2021-09-26 10:31:20.866 Error: dzVents: Error: (3.1.8) Discarding device KeukenDimmer. No last update info found: {["lastLevel"]=255, ["subType"]="Selector Switch", ["deviceID"]="", ["protected"]=false, ["data"]={["hardwareType"]="Zigbee2MQTT", ["hardwareName"]="Zigbee", ["protected"]=false, ["_nValue"]=1, ["maxDimLevel"]=100, ["icon"]="Light", ["levelNames"]="Off|On|Up|Down|Stop", ["customImage"]=9, ["_state"]="On", ["levelOffHidden"]=false, ["usedByCamera"]=false, ["levelVal"]=10, ["Image"]="Generic", ["levelActions"]="", ["hardwareID"]=1962192, ["hardwareTypeValue"]=94, ["unit"]=21}, ["deviceType"]="Light/Switch", ["rawData"]={"10"}, ["timedOut"]=false, ["id"]=1333, ["description"]="", ["lastUpdate"]="", ["baseType"]="device", ["switchTypeValue"]=18, ["switchType"]="Selector", ["batteryLevel"]=-1584432432, ["signalLevel"]=-1584432504, ["iconNumber"]=208, ["name"]="KeukenDimmer", ["image"]="", ["changed"]=true}

[rrozema]

PR 4945

[EddyG]

A quote from you: " It doesn't fix the lastUpdate not being valid" So it would be nice if the cause could be found.

[rrozema]

Yes, but that is in the various hardwares. Some of those have probably in there already for a long time. Like f.e. the Dummy hardware. I don't think that was recently changed causing the lastUpdate not to be set initially. The 'correct' message is only going to show when someone enables debug on dzvents, so nobody is proably going to notice anymore once this bug is out. Only if the user happens to notice that one of their devices doesn't trigger in dzvents, they will enable debug mode and then probably they won't be able to reproduce anyway. Still it's worth fixing the hardwares too, as it makes the whole more reliable.

[fvdp80]

Big thnx to rrozema for helping out!