Is anybody running into a driver size limit when uploading?
I’m working with a device that has a lot of preferences that change the appearance of the device in the UI (enable / disable features). This means I have around 60 or so static profile combinations to cover all possibilities.
After some recent code changes I’m now receiving a constraint violation for “SizeError”:
If I build the package rather than upload it then the resultant .zip comes in at about 140KB.
I assume therefore that this limit is for source code? If so, 524KB for driver source doesn’t seem very big!
The size of the directory for the source of this device driver is around 724KB.
I assume there’s no way around that?
I could trim it right down if there were a way to dynamically build profiles or assemble them from component parts, but I don’t believe that’s possible?
Thanks for sharing the details about the issue. To help us better understand the root cause and resolve this constraint violation, could you clarify what factors contribute to the driver size limit? For instance:
Does the system weigh specific components more heavily, such as the number of preferences in the profile or the overall lines of code in the driver?
Are there specific file types or metadata that occupy more space within the package?
We noticed that the error appeared after some recent code changes. Could it be related to a specific section of the code, like a large increase in static profile combinations or additional features added to the driver?
Unfortunately I’m not privvy to what the SmartThings system is using to determine what is causing the device driver to generate the “SizeError” when attempting to upload it.
As I mentioned, the total source code size for this device driver is about 724KB:
If I remove a bunch of the device profile .yml files then the device driver no longer generates the error and uploads fine.
The constraint violation error refers to a “total bytes” of 524288 so I assume this is refering to the size of the source code rather than the package .zip, since the package .zip file is only around 140KB.
They certainly aren’t using the vanilla Public API when deploying so they may be exempt from size limits.
Are all these profiles about enabling different presentations of a single device, or are they effectively different devices at the driver level? I was just wondering if there was scope for some creative use of visible conditions to prune things a little.
Ideally I’d like to use some sort of “include” thingy to piece the profiles together from parts. That would drop the source code burden down significantly. I haven’t seen anything to indicate that’s possible though
That sounds interesting, are there any examples of that anywhere?
I guess the alternative would be to split the sub-drivers out into their own individual top-level folders, but that would be a pain.
I guess it depends on what exactly is ‘different’ about the devices that use the sub-drivers. Supposing your main driver was written to support the ‘dimmer switch with metering and remote’. Would it need to be changed, and if so could it be changed, to also support the ‘dimmer switch with metering’ and the ‘dimmer switch’? I think that better reflects how the stock drivers work. The main driver tries to cover everything it can and then the sub-drivers are created because certain elements work differently to the way the main driver handles them.
Are you also using allowing different categories for devices? That’s expensive in profiles. Is it gaining you more than a different default icon that the user could select anyway? If not then is it a price worth paying?
It used the visibleCondition key in device configs so a search on this community is as good as any.
They work by only displaying attributes if an attribute somewhere in the device (any component, any capability, and any attribute) meats certain conditions. The drawback seems to be that in the device detail view they grey out rather than hide the tiles. That’s perhaps OK if the user is aware they are only opting to use part of the functionality of a device, not so useful if the device doesn’t have that functionality to start with.
Yeah I went the other direction, so the main driver does the “common” functionality and then the sub-drivers build on that to add features if needed.
Yes, although I can’t recall why I went down that route. I think it was to do with different things being available in the UI / Automations based on what category the device was in (Light vs Switch for example). It might have also been Alexa / Google related, I think there might have been a difference in behaviour there depending on what category the device was from.
Ah, that may have been another reason, I don’t think it was possible to change the icon historically.
Perhaps I should revisit that and test to see what the current situation is, it would knock off a large amount of profiles if I didn’t need to do that!