Looking for a best practice: when you get a regular stream of data from physical devices (in my case a LAN devices), and need to update device capabilities with that data, it’s likely that 90% of the time the data values haven’t actually changed. In this case is it a best practice to first check the state_cache myself and not call emit_event if the value hasn’t changed? Or does Edge do this anyway when I invoke the emit_event and therefore a state_cache compare is unnecessary within the driver. I’m looking to minimize the load on SmartThings calls, as there can be a large number of devices each generating numerous capability updates on a regular basis. Of additional concern is hitting rate limits.
1 Like
AFAIK emit will eventually check against the state cache and it will process the event always and include other overhead actions like checking rate limits, processing if it should be reported or displayed etc. I think it’ll be less overhead to check state cache before emiting the event. I use this logic to keep the driver efficient
1 Like
Hi @TAustin
I don’t know how status reports are configured for LAN devices, but for zigbee, which are normally the most talkative, autonomously, in terms of sending attribute reports.
I think the main thing should focus on controlling the root of the problem to reduce excessive emission of events.
On zwave and zigbee devices, events are only emitted when a status message is received from the device and attributes are not normally polled or read periodically on the devices. Only when the Health check is executed in Zigbee when the configured reports are not received.
If we manage to reduce the number of messages that the device sends to the minimum necessary, we will simultaneously reduce both the workload of the Hub and the traffic on the internal zigbee and zwave networks.
There are capabilities that in the app have options to show graphs, energy, temperature, humidity, battery, contact that use all events, including those that do not have a state change, to generate the graphs.
For example, the battery case, if events are stopped being sent without a state change, it would only show the events with changes and the graphs could remain empty for weeks.
So I think we should rethink whether the 300 sec periodic reports are necessary for the OnOff, IASZone attributes that are used in most of the zigbee devices that we have at home, switches, plugs, lights, contact sensors, movement, water leak and even 180 sec interval for Smoke, CO and Gas sensors.
Some time ago @csstup reported it as something to could change.
This would not only reduce the work of the Hub and networks, it would also improve the battery life of these devices.
The reportable changes in power and energy have already been expanded in the defaults from 1 w to 5 w and from 1 w/h to 5 w/h, I don’t know if they could be increased without losing precision or effectiveness in the triggering of routines that use these capabilities.
I am trying with several devices, contact and motion sensors, changing the maximum intervals from 300 sec to 600 sec and others to 900 sec and others to 1200 sec, everything is working perfectly without being shown offline at any time and the traffic It has been reduced a lot and I hope the batteries start to last much longer.
I will start testing these changes also with switches and bulbs
I am implementing it in a preference so that the user can configure it to their liking from 180 sec to 3600 sec. and I will determine the final default when I finish all the tests.
- name: "iasZoneReports"
title: "Select Contat Sensor Interval Report"
description: "Select Contat Sensor Interval Report (180 sec to 3600 sec). Default = 300"
required: true
preferenceType: integer
definition:
minimum: 180
maximum: 3600
default: 300
Is needed to change the attribute monitoring interval too, otherwise the health check would be activated with the old interval report multiplied by 1.5 sec
elseif id == "iasZoneReports" then
-- Configure iasZone interval report
local config ={
cluster = IASZone.ID,
attribute = IASZone.attributes.ZoneStatus.ID,
minimum_interval = 30,
maximum_interval = device.preferences.iasZoneReports,
data_type = IASZone.attributes.ZoneStatus.base_type,
reportable_change = 1
}
device:send(IASZone.attributes.ZoneStatus:configure_reporting(device, 30, device.preferences.iasZoneReports, 1))
device:add_monitored_attribute(config)
end
I am doing it this way because even if smartthings changed the defaults now and applied them, they would have no effect on the devices already installed and working, only on those that were installed after the change or uninstalling and installing all the devices already in operation.
The dynamic change from preferences is working well on Samjin devices and some TUYA devices that I have.
@TAustin I think it is a good topic to discuss, I can’t talk about LAN devices, I don’t know them and the Zwave are much less talkative, they only speak when asked and the power report intervals are normally configurable with parameters.
1 Like
Good stuff. You are ahead of the curve!
What is less-than-ideal in the driver I’m working right now, is that it does have to poll the device. And in this case, the device is a hub, with possibly many device (thermostats) under IT. The interface to this hub device is a secure web sockets API with commands needing to be initiated by the client app (my driver in this case). It doesn’t have any asynchronous notification of state changes. So that’s what was behind my original question. To your thought on configurable settings, I definitely provide a update frequency setting so the end user can ultimately decide on how up-to-date they need their data.
There are different challenges between these devices types, so it’s good to bring up related issues and learn from each other…
I took a look at the old alpha-level Edge libraries to see if I could determine if and when a state cache check is done with a normal emit_event, but there’s really not much going on in the Lua code - just some basic validity checking. The important stuff is in the Rust code and/or back in the server.
It would be great if someone from the development team could enlighten us more on this point. If a state_cache check is done ‘early’ in their processing, it might be redundant to include it in drivers. But I suspect you are probably right that it’s worth it to reduce processing overhead.
The default zigbee and zwave libraries do not seem to do any checking of the current state before emitting the event.
In fact, the event is always emitted when the periodic report is received or the device is read, even if the state has not changed.
The app only shows in its history the events that have changes, but the server has all the events and they are used, for example in temperature graphs
In the hour graph it shows the average of each hour
The real way to reduce network traffic and hub work is to reduce unnecessary messages from the device to the hub.
This sensor only sends reports every 1 hour or temperature changes of 0.1°
