Aqara sensors stopped working?

It’s odd isn’t it, Joka…

Here’s the code I used.
This is your code copy/pasted:


Replacing it with alarm_motion results in the same error msg
.
Here I replaced alarm_contact with measure_battery:

.
The code with alarm_contact again, but now without substring(0,10)

.
Is it a version thing?
Homeyscript v3.4.1
Homey v8.0.3-rc-7

There’s probably one sensor that doesn’t have the lastUpdated property.

This might work better:

array.push( device.capabilitiesObj.alarm_contact.lastUpdated?.substring(0, 10) + ' ' + device.name);

It will only call substring() if lastUpdated is defined.

2 Likes

That’s an option and good idea. I assumed that every alarm_contact has a lastUpdated property. Maybe a Virtual Device? With VD I was able to generate an alarm_contact without a lastUpdated property.

But anyway @Peter_Kawa you should be able to identify the device with:

const devices = await Homey.devices.getDevices({ filter: {class: 'sensor', capabilities: 'alarm_contact'} });
_.forEach(devices, device => {
if (!device.capabilitiesObj.alarm_contact.lastUpdated) log(device);
});
1 Like

That did the trick, Robert! Thx!
@Joka There is a v motion sensor indeed, which returns “undefined”. So that problem’s solved.
But I can’t find an issue with the contact sensors.

Script with ?.substring(0,10):

Script without ?.substring(0,10):

I have to mention “Deur/Raam” is a < group > app device, with all contact sensors in it.

.

This returns nothing…

Thanks in advance guys.

Deur/Raam seems not the problem its date is trimed with substring. Please let me see the error message of the alarm_contact sensors again.

Are all of your alarm_contact sensors in the list? If you want you can send me the result of the following as PM:

const devices = await Homey.devices.getDevices({ filter: {class: 'sensor', capabilities: 'alarm_contact'} });
_.forEach(devices, device => {
log(device);
});

This is the previous posted error message.

But (I can’t stand this) atm, it returns all of my 5 contact sensors without errors :face_with_raised_eyebrow:

Yup

Will do, thanks i.a.
There’s no error anymore, but it might reveal something to you.
In the returned data, I counted all of my 4 sensors (lastUpdated alarm_contact, alarm_battery, measure_battery) and the group sensor device, which has only lastUpdated alarm_contact.

So, no error with the alarm_contact anymore if I understand you right.

The only reason I can imagine is that your Virtual Device (alarm_motion) which you fixed included also the capability alarm_contact. In this case the alarm_contact doesn’t included the lastUpdated property. This would result in the error.

Example of a VD with both capabilities:

__athom_api_type: ‘HomeyAPI.ManagerDevices.Device’,
id: ‘xxxxx’,
name: ‘New Device’,
driverUri: ‘homey:app:com.arjankranenburg.virtual’,
driverId: ‘virtual_switch’,
zone: ‘xxxx’,
zoneName: ‘Zuhause’,
icon: ‘window_open.svg’,
iconObj: {
id: ‘xxxx’,
url: ‘/icon/xxxx/icon.svg’
},
settings: { energy_value_constant: null },
settingsObj: true,
class: ‘sensor’,
energyObj: { W: null, batteries: null, cumulative: null, generator: null },
capabilities: [ ‘alarm_contact’, ‘alarm_motion’ ],
capabilitiesObj: {
alarm_contact: {
value: null,
type: ‘boolean’,
getable: true,
setable: false,
title: ‘Contact alarm’,
desc: ‘Contact sensor, e.g. for windows (true/false)’,
units: null,
id: ‘alarm_contact’,
options: {},
values: undefined
},
alarm_motion: {
value: null,
type: ‘boolean’,
getable: true,
setable: false,
title: ‘Motion alarm’,
desc: null,
units: null,
id: ‘alarm_motion’,
options: {},
values: undefined
}
},

Correct. It boggled me why it suddenly worked OK.
Finally it came to mind.
Because of the virtual motion sensor issue, I removed that.
AND appearantly a virtual contact sensor as well; totally forgot about that.

So I restored a backup, to have the virtual sensors back, and the setting. Now the script returned the faulty virtual contact sensor. It’s lastUpdate value is null (while I never set a state through a flow), just like the virtual motion sensor.
Returned data snippet:

capabilities: [ 'alarm_contact' ],
  capabilitiesObj: {
    alarm_contact: {
      value: null,
      type: 'boolean',
      getable: true,
      setable: false,
      title: 'Contact alarm',
      desc: 'Contact sensor, e.g. for windows (true/false)',

I’m also having trouble with Aqara sensors that stop reporting after a while. This seems like a common issue, sadly - but as far as I understand it, the issue does not occur with Deconz, so sounds like it’s a Homey issue. Has anyone from Homey actually looked into this?

Well I didn’t have any trouble with 12 Aqara sensors (temp/contact/motion), until I added Ikea lights.
But, after adding a Tuya Zigbee app and end-device, zigbee is rock-solid (a pure coincidental discovery).
Athom has no Aqara app, and will point at the Aqara app developer I’m afraid.

I’m facing this Aqara issue only for some of my sensors.
I’ve seen in developer ZigBee map, that sensors with this issue are routed via INNR SP220 plugs. and these plugs had vvery bad routes (2x throught the whole house over 3 levels). I replaced one of the plugs wich covers the garden area with an old Osram plug. For some days I have a stable connection to the temperature sensor outside.
I can’t remember when this issue started. But I replaced some Osram plugs with INNR (some SP120, some SP220 since 120 is not available anymore. Perhaps this is related. Because only sensors far away which are routet over such INNR pugs are affected.

The distance from Homey do indeed seem to play a part. I had two sensors with around 3 meter distance difference. One working flawlessly and the other one stopping to work after some days.

Happy with my switch to Fibaro multisensor and sensative guard strips, both z-wave.

A short reply with my experiences…
I removed the innr SP220 plugs and placed them into the Hue mesh. The SP120 from from Hue I moved into the Homey mesh.
Only the innr SP120 and some Osram plugs are used now as repeater.
While checking the Zigbee developer page I saw some devices with white question marks in the routing list. I can’t say if this occoured with the imported backup on another Homey. These devices were still working but I reincluded them to prevent problems with a corrupted mesh. After this reorganisation was done, all is working fine now. No Aqaras stopped working yet.
I can’t remember if the problems with Aqara started exactly with the new innr plugs. But I hope it’s solved now.

I had similar experience, also re-added them without removal just to prevent issues even they were responsive (and despite the fact I have been reassured it’s OK by Athom support, I simply think it’s not :wink: ). Last time it happened like 6 months ago and since then, knocking on the wood, it’s stable.