jang

I think these are icons for shown in the UI when configuring the Button. Not the ones it displays as the state changes.

Yay!

Some devices/plugins carry with them icons for the UI - settings etc. This is not the same as the icons used to switch between the states of the device.

Why would it need 10 icons? What are the states?

The types mapped in QuickAppBase.deviceIconTypeMapping by Fibaro are: com.fibaro.powerSensor com.fibaro.heatDetector com.fibaro.windSensor com.fibaro.windowSensor com.fibaro.rainDetector com.fibaro.gasDetector com.fibaro.player com.fibaro.genericDevice com.fibaro.humiditySensor com.fibaro.multilevelSensor com.fibaro.energyMeter com.fibaro.motionSensor com.fibaro.deviceController com.fibaro.rollerShutter com.fibaro.baseShutter com.fibaro.multilevelSwitch com.fibaro.doorLock com.fibaro.temperatureSensor com.fibaro.fireDetector com.fibaro.doorSensor com.fibaro.binarySensor com.fibaro.coDetector com.fibaro.floodSensor com.fibaro.binarySwitch com.fibaro.smokeSensor This means that we can upload iconsets for these types (and probably super types that has these as base types) If not mapped we can at least assign a single icon to them.

There is no ready made function - you have to do it yourself. function QuickApp:iconCount(typ) local map = { [QuickAppBase.iconProviders.single]=1, -- single icon [QuickAppBase.iconProviders.binary]=2, -- off,on [QuickAppBase.iconProviders.multilevel]=11, -- 0%,10%,20%,30%,40%,50%,60%,70%,80%,90%,100% [QuickAppBase.iconProviders.baseShutter]=5 -- opening,opened,closing,closed,unknown } local iconProvider = QuickAppBase.deviceIconTypeMapping[typ] or "" return map[iconProvider] end function QuickApp:onInit() self:debug(self.name, self.id) print(self:iconCount("com.fibaro.energyMeter")) print(self:iconCount("com.fibaro.multilevelSwitch")) print(self:iconCount("com.fibaro.baseShutter")) end iconCount returns number of icons for a specific type. Currently there only seems to be 4 options, 1,2,5,11 icons. If it is not mapped (return nil), try with the device baseType and see if that is mapped. ...or Fibaro has forgot to do the mapping.

Like this?

We can't disable or change font/color of button (except for unicode characters) I understand that you would like to disable one option but still show the user that the option exists. "There is Open Door, but it's not available right now" An alternative, that may be understandable for the user, is to have a single button that serves both functions and changes text between "Open Door" and "Close Door". Another alternative is to change the text of the inactive button to be strike-through letters (unicode), "O̶p̶e̶n̶ ̶D̶o̶o̶r̶" https://www.contentharmony.com/tools/strikethrough-text-generator/

Well, it's a bit tricky. If you use setProperty, it will not call the QAs updateProperty method. Some QAs may have written code to override the logic for QuickApp:updateProperty and then it's not called. The other problem is that the Device:updateProperty that QuickApp:updateProperty inherits from, do update the QuickApp's objects self.properties[prop]=value If we only call setProperty, self.properties.value will differ from fibaro.getValue(self.id,"value") which could cause issues for some QAs... One could check if the device is a QA and call updateProperty, and if not call setProperty... local isQACache = {} local function isQA (id) if isQACache [id]~= nil then return isQACache[id] end local d = __fibaro_get_device (id) if d then for _,i in ipairs(d.interfaces) do if i == 'quickApp' then isQACache[id] = true return true end end end isQACache [ id ]= false end takes on average 10ms per QA for my 200 QAs. And the result is cached so checking same id is then fast...

This only works if the device is a QA. QuickApp's have 'updateProperty' defined as an API. I would recommend api.post("/plugins/updateProperty", { deviceId = 20, propertyName = 'userDescription', value = 'FWPP1' })

No there is no reason. Except maybe a wish to bring all functionality in under fibaro.* - but they can't remove setTimeout due to old QAs/Scenes. function fibaro.setTimeout(time,fun) return setTimeout(fun,time) end Like the rebranding of fibaro.* to hub.* - but also here, to be backward compatible with QAs/Scenes they can never remove fibaro.*... Another mystery is that Fibaro maintains 2 implementations for the fibaro.* functions. One for Scenes and one for QAs - and they are not always in sync... My thinking has been that it is 2 different consultant companies that do the Scene engine vs the QA framework... :-)

Have you tried it? Did it work for you?

What kind of animal is Conso Live (Enphase_MeterTotalConsumptionPower_Updated) that is expect to send an event/signal. Another QA? another zwave device? something else?

Problems: 1. You set 'value' but test 'state' 2. If you click 'off' -> 'on' quickly you may end up with 2 running loops... I think @laser meant something like this (but here we use the property instead of a local var) local function loop() if (hub.getValue(plugin.mainDeviceId,"value") == true) then print("Run Loop action") end -- loop setTimeout(loop,1000*loop_value_sec) -- secondes end loop() function QuickApp:turnOn() self:debug("binary switch turned on") self:updateProperty("value", true) end function QuickApp:turnOff() self:debug("binary switch turned off") self:updateProperty("value", false) end

Unfortunately not. I have QAs that don't work on the HC3L because I use os.time() a lot. os.time(), these days, returns a value dangerously close to what fits in 32 bits and when doing arithmetics with the value, calculating time, it sometimes overflow and create bad results on the HC3L... So, I recommend the HC3L only for block scenes... For dev platform I use https://forum.fibaro.com/topic/66394-visual-studio-code-vscode-for-quickapp-development/ Life is too short for trying to develop directly on the HC3/HC3L...