PERL WARNING: for reference only

[fruit]

Please move if there is somewhere more appropriate

It has taken me some time to track these so I thought it worth posting this as a reference for future searches.

For some time I have been seeing errors similar to

Code Auswählen Erweitern

2014.11.01 16:49:20 1: PERL WARNING: Use of uninitialized value $val in concatenation (.) or string at fhem.pl line 1384.
2014.11.01 16:49:20 1: PERL WARNING: Use of uninitialized value $val in substitution (s///) at fhem.pl line 1383.
2014.11.01 16:49:20 1: PERL WARNING: Use of uninitialized value $val in substitution (s///) at fhem.pl line 1382.

on every Save config.

I had two empty attribute fields (possibly autocreated a long time ago). Deleteing them has removed the errors.

[rudolfkoenig]

You called save, while one of the attribute values was undefined.
Such attributes should not be created by FHEM, if you know how to reproduce it, please tell us.

[fruit]

Yes, I know that now It wasn't easy to find though, especially on the RPi.
Viewing logs through the web interface at verbose 5 and with stacktrace enabled was almost impossible, only since moving to a Cubietruck have I been able to track this down.

One is certainly reproducible.

I had an LED-status monitor as in http://www.fhemwiki.de/wiki/1-Wire_LED-Statusmonitor defined that is not connected at present.
Adding back the definition, but not adding the device produces

Code Auswählen Erweitern

define ds2408_LED OWDevice 29.AC5413000000
attr ds2408_LED IODev myLocalOWServer
attr ds2408_LED model

The attribute is recreated if deleted.

It's possible that with the device connected the attribute is populated - but I don't have the device available at the moment - for this reason I'm not sure whether it should be flagged to the OWDevice developer.


The other device is a Homematic HM-WDS100-C6-O weatherstation, through an hmusb adapter and I have a feeling that the empty attribute was created when the device was added about a year ago. I don't remember adding it and see no reason as to why I would have.

Code Auswählen Erweitern

define WeatherStation CUL_HM 1FCD3A
attr WeatherStation .devInfo 3F0100
attr WeatherStation .stc 70
attr WeatherStation IODev hmusb
attr WeatherStation actCycle 000:10
attr WeatherStation actStatus alive
attr WeatherStation autoReadReg 4_reqStatus
attr WeatherStation expert 1_on
attr WeatherStation firmware 1.4
attr WeatherStation fp_MyPlan 30,1100,1,
attr WeatherStation model HM-WDS100-C6-O
attr WeatherStation peerIDs
attr WeatherStation room WeatherStation
attr WeatherStation serialNr KEQ0241679
attr WeatherStation subType THSensor

Attribute peerIDs is not recreated on deletion so, if it was autocreated back then, it seems OK now - the HM modules have been updated many times since installation.

I hope that is enough of an explanation.

Edit: I have just found a saved cfg from 2013-11-28, a day after I added the Weatherstation, it has the empty attribute.

[rudolfkoenig]

The FHEM command

Code Auswählen Erweitern

attr WeatherStation peerIDs
is converted internally to

Code Auswählen Erweitern

attr WeatherStation peerIDs 1
If a module is setting the attribute directly to undef, than this is a bug in the module, it should delete the attribute instead.

[fruit]

Thanks for the reply. I am not quite sure where that leaves me.

I deleted the ds2408_LED 1-wire device but was still seeing the error on save. Only after deleting the WeatherStation attr did the save error disappear - and the weatherstation is still working and reporting as before.

My assumption now is that the attribute is not required in my situation ('list WeatherStation' does not include a peerID entry), so that would suggest that it should have been deleted by the module?

[rudolfkoenig]

 Deleting a device via the FHEM call "delete" will delete all its attributes completely. If you are not manipulating attributes with perl code like { $attr{WeatherStation}{peerId} = undef }, but only using FHEM commands like attr, deleteattr, delete, etc then it is almost certainly a module problem, and should be reported to the module maintainer in the appropriate forum section, describing what you've done before with the device, as the error message alone won't be enough. E.g. a possible problem can be an internal timer, which checks the attribute value, without checking that the device is already deleted.

[fruit]

Thanks. I'll add a post in the HM forum, probably tomorrow, as I am away for the rest of the day. I guess another in the 1-wire as well.

My short initial description was simply to add a placeholder for the error messages in case anyone else searches for the same. It took me some time to track down the exact cause as there was no (attribute) value in the message as a clue.