prop.onState <-> dev.states["onoffState"] <-> dev.onState

to answer my question:

Screen Shot 2018-10-12 at 13.34.51.png (6.92 KiB) Viewed 2820 times

yes it does

Code: Select all

                     keyValueList = []
                     keyValueList.append({'key':'onOffState', 'value':not dev.onState,"uiValue":"text abc"})
                     dev.updateStatesOnServer(keyValueList)
                     dev.updateStateImageOnServer(indigo.kStateImageSel.Auto)


Karl

but still the question how to change the devicetype not the devicetypeID in the plugin ( re-read the devices.xml file and force update from <Device type="custom" .... to <Device type="sensor" ...)

when I just change <Device type="custom" .... to <Device type="sensor" and reload the plugin the device does not read this and continues the old "custom".

Tried
"dev.replaceOnServer()"
does not do its.

Karl

[matt (support)]

Take look at this post. I'm not positive that API will work in this case, but give it a try.

Thx.


Sent from my iPhone using Tapatalk

This works in

Code: Select all

      def deviceStartComm(self,dev):
         if self.pluginState == "init":
            dev.stateListOrDisplayStateIdChanged()   # update  from device.xml info if changed
            if self.version < 32.50:
               if dev.deviceTypeId in ["Wire18B20","DHTxx","DHT11","i2cTMP102","i2cMCP9808","i2cLM35A","i2cT5403","i2cMS5803","i2cBMPxx","tmp006","i2cSHT21""i2cAM2320","i2cBMExx","bme680","si7021"]:
                  props = dev.pluginProps
                  if "SupportsSensorValue" not in props:
                     dev = indigo.device.changeDeviceTypeId(dev, dev.deviceTypeId)
                     dev.replaceOnServer()
                     dev = indigo.devices[dev.id]
                     props = dev.pluginProps
                     props["SupportsSensorValue"]       = True
                     props["SupportsOnState"]          = False
                     props["AllowSensorValueChange"]    = False
                     props["AllowOnStateChange"]       = False
                     props["SupportsStatusRequest"]       = False
                     dev.replacePluginPropsOnServer(props)


this reloads the newly defined device definitions from the xml file ie the deviceType and sets the proper sensorVales settings

thanks so much .. this make everything a lot easier !!

Karl

still have to go through the onOff devices and some fine tuning..

a little closer to indigo standard

[matt (support)]

Great – I'm glad it is working (it was untested I believe in this scenario)! Thanks for the follow-up.

question:

on page: https://wiki.indigodomo.com/doku.php?id=indigo_7_documentation:device_class
it has "allowSensorValueChange" as device class property

while in the sensor example the property is:

Code: Select all

         <Field id="AllowSensorValueChange" type="checkbox" hidden="true" defaultValue="false">
            <Label>Enable controls to override sensor value state</Label>


with a capital A -- which seems to work setting it to True/ False

AllowSensorValueChange vs allowSensorValueChange.
same for AllowOnStateChange etc.

are these different props, spelling error .. ?

Karl

[matt (support)]

They are the same properties. All device instance properties start with lowercase (so dev.allowSensorValueChange), but when overriding those via a pluginProps dict we use "AllowSensorValueChange". Internally they are different things – some special pluginProps automatically get propagated down into an instance level property when they are changed which is what is happening here: internally when changing pluginProps["AllowSensorValueChange"] the Indigo Server pushes the change down into dev.allowSensorValueChange. I totally agree this is confusing and the underlying plumbing doesn't justify the inconsistency, but it explains why it works (because they are "special" properties that can be overwritten by a plugin that owns them). In this case the standard for capitalizing pluginProps[] entries came about independently of instance level dev.someProps and we are trying to be consistent within the scope of each.

got it .. thanks..

now how can we use allowSensorValueChange

setting SupportsStatusRequest = True shows a button "send Status Request". Thats nice I can use that one

allowSensorValueChange =True does not add any buttons.
Is it for binary devices ie to enable "indigo.sensor.setOnState(123, value=True)"

Would be nice If we could add a "reset button" to an "analog" sensor device eg counter devices eg rain sensor (almost analog) similar to reset accumulated energy *)

Karl
*) that should actually be Energy don't know what accumulated Energy is; E= integral(power dt), accumulated Energy would be Integral(Integral(power dt) dt. with power = potential * current (V*A).. if i remember physics correctly

[matt (support)]

allowOnStateChange has Indigo show/allow UI and actions for turning on/off binary sensor values, which is useful for example if there is a module that sends out an alert/tripped message (causing an ON state in Indigo) but never sends out a clear/off message (thus requiring the user to manually turn off the sensor state in Indigo).

allowSensorValueChange currently doesn't do anything but once implemented will be useful for scenarios like you describe above.

It seems that onOff devices do NOT show the UI state but the binary value in iTouch (on/off).
It shows correctly in the state column in the client

Analog sensor show the UI value in iTouch

Is that by design?

Karl

[matt (support)]

Can you screen capture an example for me?

there the 2 screen shots:

[matt (support)]

Thanks, I understand now. Added to my Indigo Touch todo list.