Indigo Domotics

Using the plugin to determine when the car left the garage or arrived back home (multiple drivers). Using the status property: distancefromHomeKm.

This works great for "away" - distancefromHomeKm becomes > than 0.02 km, but it doesn't work for "home" distancefromHomeKm becomes < than 0.03 km

Also, there is something wonky with the properties - all the properties list, but when you try to select some, they keep shifting.

Example: you try to select "distancefromHomeKm" but you get "display status". This is erratic. Sometimes you get the correct one, but sometimes you don't.

Suggestions?

JP

Can you explain a bit more?

The plugin doesn’t calculate distanceFromHome, it just provides what Tesla say - then if you’re triggering on <3 etc that’s Indigo comparing not the plugin.

Re properties, I presume you mean states. Those update dynamically so if Tesla provide new states, it populates them automatically - but the only time you see that is if you’re editing at the time the states are newly added.


Sent from my iPhone using Tapatalk Pro

Sorry, let me see if I can be from clear.

On a trigger, you try to select a state from the list, but the item you select from the list, is not the one that shows on the selection. The items are schew one sometimes two places.

Tesla is providing the correct information and the plug is providing it. I beleive the issues is that the states in the plugon are not aligning to the actual states in the Tesla.

Makes more sense? I have attached 3 images that hopefully will show the problem.

JP

Howard, just wanted to let you know that what roquej is reporting happens for me as well.

Steps to reproduce:
- Create new trigger "Device state changed"
- Select a Tesla device, in my case "Tesla Battery Level""
- Click the next line to select the state you want the trigger on

Now, when you select a particular state from the dropdown, that's not the state that shows in the selection field. It usually takes a few attempts clicking "on or around the desired state", to get the desired state selected.

Not a major deal and things work fine once this hurdle it taken, but this is such a lovely plugin; let's make it perfect. Happy to help test things for you if desired!
Ronald

@Matt @Jay

Thoughts on this one please?

I've just started up the plugin on my Mac (I don't have it live as it's not my Tesla). I still have device on my system, just disable the plugin.

The plugin only defines five states in xml, the rest are added dynamically when refreshing from Tesla, so that any new states provided in the return data are automatically added and populated.

I went to create a trigger and the only device-state-changed states I could trigger on were the five states defined in the xml.
However if I go look at the device itself in the devices UI, I can see all the states that existed when I last used it, so the device does have all those states.

I ran the action group to refresh all states, which found several new states (it's months since I had plugin enabled so perfectly expected that Tesla added new ones since) then correctly shows all the states in both trigger definition and device UI.

Now, given I've witnessed a disparity between the trigger UI state list and the device UI state list, it doesn't surprise me at all that both posters on this thread are able to see different items showing - I presume you somehow index the selection dialog so if a new state is added earlier in the alphabet, it throws the row numbers out? (Not sure why, as I'd expect you are indexing on state name or a state UID at creation, but something is getting out of sync?)

Peter

I glanced through the code to refresh my memory as to how this Trigger device state popup UI works. It builds the popup menu item list when the dialog is first opened and at various points when other dependent UI is changed in the dialog (like Trigger type). It does this by calling into the plugin's getDeviceStateList method. By default that method builds the list from the plugin's XML but it sounds like for this plugin it is dynamic (so it must define an override of the method).

Upon selection of an item in the popup menu list it then determines which item is selected based on the index of the item in the list that was selected. It then calls getDeviceStateList again to determine the state information for this Nth selected item.

If between those two calls to getDeviceStateList the returned list changes then the selected item won't match what is actually selected. I presume it is possible that is the case here? That is, the returned list from getDeviceStateList is changing over a short time period?

Clearly we need to make Indigo more robust in this case.

Just realised I never came back to this; I read it on my phone but didn't take it in properly without my code in front of me.

getDeviceStateList is overridden in the plugin, yes.

I don't think the output changes frequently - typically it would be at plugin startup, device save, plus if Tesla send new states in the API return that I weren't there last time - I then rebuild the state list with the new info from Tesla, so I don't have to keep updating the plugin as they add new state info.

However, yes it seems some work on robustness would come in handy; can I call updateStateListInIndigoTriggerUISoThatIt'sUpToDate() anywhere?

Peter

howartp wrote:

However, yes it seems some work on robustness would come in handy; can I call updateStateListInIndigoTriggerUISoThatIt'sUpToDate() anywhere?

Indigo polls out of the plugin (by calling getDeviceStateList) the information both when the UI is first shown and then again upon selection of a popup in the state menu list. So the problem should only occur if those two calls (which should happen in a relatively short period of time from one another, unless the user leaves the dialog open a long time) return different data. It sounds like that is possible but based on your description unlikely, which is a bit puzzling.

Can you put some debug logging code in your plugin's getDeviceStateList() that dumps to the Event Log the result it is returning to Indigo? Maybe also cache off the value in the plugin then compare that to the currently returned value to see how often it really changes? Something like this (untested):

Code: Select all

# put this in plugin init
self.lastReturnedStateList = None

# put in getDeviceStateList right before it returns
if self.lastReturnedStateList is not None and self.lastReturnedStateList != stateList:
     indigo.server.log("state list changed")
     indigo.server.log("old state list: %s" % unicode(self.lastReturnedStateList))
     indigo.server.log("new state list: %s" % unicode(stateList))
self.lastReturnedStateList = stateList
return stateList

Then see if it logs that the state lists changed when (and only when) the bug in the UI happens?

Thanks Matt

That code is added to 1.0.19 that i've just pushed to the store with the 1.0.18 changes in.

Peter