Cannot read property ‘maxFloorTemp’ of undefined.

[arnljot]

Same as in #7. I have three of mine running in "frost guard" since the rooms they control are now being heated by underfloor heated water controlled by Roth. The fourth is running in thermostat mode with floor sensor.

My products are the Elko Super TR.

These will experience “Device is unavailable. Cannot read property ‘maxFloorTemp’ of undefined.” which can only be fixed by restarting the Elko app. This will happen a short while after the app is restarted.

I'm running the latest version of the app, 1.0.10.

Just to clarify:

• Thermostat 1, 2 and 3 are running in frostguard mode.
• Thermostat 4 is running in normal heating mode with floor sensor (was misconfigured, but changing didn't fix it).
  
  
  
  
  
  
  
  

[arnljot]

The only places the bug can happen are at these lines:

com.elko/drivers/ESHSUPERTR/device.js

Line 163 in afd96d7

this.setCapabilityValue('maxFloorTemp', value.maxFloorTemp)

At this point it means that the await has returned with "undefined". It can't fail on line 164 or later in this block, because it would have failed on 163.

com.elko/drivers/ESHSUPERTR/device.js

Line 670 in afd96d7

this.log('Thermostat max floor temp changed: ', event.newSettings.maxfloortemp);

This is where changes to the settings by the user are handled. This is a likely place to me that it can fail. But I don't quite see how yet. 670 is the first codeline in this block where this attribute is accessed by something that can be undefined (newsettings). In the following lines 672, 673 and 674 the accessor in 670 would terminate the code block before it gets there.

So the bug either happens when the settings are applied or when the attribute is about to be read from the device.

[arnljot]

Actually, I think the problem happens in the following lines, and spesifically on line 163.

com.elko/drivers/ESHSUPERTR/device.js

Lines 159 to 163 in 5330456

	// Set Thermostat Maxs floor temp
	if(this.hasCapability('maxFloorTemp')) {
	const value = await zclNode.endpoints[1].clusters[CLUSTER.THERMOSTAT.NAME].readAttributes('maxFloorTemp')
	.catch(err => this.error('Error reading max floor temp: ', err));
	this.setCapabilityValue('maxFloorTemp', value.maxFloorTemp)

I don't know yet. But I think that for some reason, this await returns with undefined as a result, and not the expected value object.

And since this code isn't in a try catch block or has a "undefined guard" before accessing the attribute, it bombs out and crashes the driver in Homey and is paused.

The code in lines 670 are all within a try catch block, and as such would not crash the driver code.

[arnljot]

I believe the problem is that the device has the capability of "maxFloorTemp", but since my devices are either running in "floor sensor" or "frost guard" and none of them in "Supervisor Floor" mode. The code crashes in line 163 as there is no try catch or check there.

Because my devices aren't running in "supervisor floor" mode, I think the devices return undefined when it's attempted to read taht attribute from the cluster. And thus the crash. I think line 160 should be changed to "if sensormode is supervisor floor and has capability".

Or at least only wrap the block inside the if in line 160 in a try catch.

[arnljot]

Maybe the correct place to fix the device is in the following code block:

com.elko/drivers/ESHSUPERTR/device.js

Lines 631 to 653 in 5330456

	async onUpdateMode(value) {
	try {
	if (value === false) {
	await this.addCapability('target_temperature');
	await this.addCapability('measure_temperature');
	await this.removeCapability('dim.regulator');
	//await this.setSettings({
	//regulatorMode: false
	//});
	await this.log('Added target_temperature, removed dim.regulator')
	} else if (value === true) {
	await this.removeCapability('target_temperature');
	await this.removeCapability('measure_temperature');
	await this.addCapability('dim.regulator');
	//await this.setSettings({
	//regulatorMode: true
	//});
	await this.log('Added dim.regulator, removed target_temperature')
	}
	} catch (err) {
	this.error('Error when trying to change operating mode: ', err)
	}
	}

This coded attempts to switch capabilites on/off for the device based on what mode it's running in (regulator or thermostat), but fails to consider that the thermostat mode has three sensortypes

• air
• floor
• supervisor floor

According to the manual, if it's in supervisor floor two temps can be set. If supervisor floor mode is off, then one of the two other sensormodes (air or floor) must be switched on, and max floor temp is moot.

Norwegian manual:

I believe that either the code block for thermostat mode:

com.elko/drivers/ESHSUPERTR/device.js

Lines 633 to 641 in 5330456

	if (value === false) {
	await this.addCapability('target_temperature');
	await this.addCapability('measure_temperature');
	await this.removeCapability('dim.regulator');
	//await this.setSettings({
	//regulatorMode: false
	//});
	await this.log('Added target_temperature, removed dim.regulator')
	} else if (value === true) {

Should be made to consider what sensor mode it's running, swithcing on "maxFloortemp" capability only for supervisor mode floor.

Or the code in 160 must be hardened to handle that the capability isn't really available because the device isn't running in the relevant mode for the device to provide such readings.

[arnljot]

This is frustrating, I forked the code and installed the beta branch version on my own homey, thinking I would make a patch and a pull request. Before I reinstall all my Elko devices, is the "could not get device by id" error messages I get because each install has exclusive access to the devices, or a bug in the current beta code I checked out and installed?

I'm hesitant to set up these devices all over again... It's a chore, and would prevent me from contributing to this codebase.

[frodeheg]

Does it get back into a working state when you reinstall the public version?

If so I would suggest you to just edit the app.json file and set
"id": "com.elko2",

This way you can debug the app in parallel with your existing app.

[arnljot]

Does it get back into a working state when you reinstall the public version?

If so I would suggest you to just edit the app.json file and set "id": "com.elko2",

Ah, yes! Thank you, I didn'y notice that one. Yes, it goes back to working when I reinstall the public version.