use custom states from a ghost xml device

[bsp9493]

Not sure if this belongs here or somewhere else...

I have a ghostXML device setup that returns a number of custom states. (ie 2 different temperature values)

I need to calculate and then monitor the differential temperature between 2 of these values (ie 120 degrees - 80 degrees = 40) and then either store the number in a variable, or use the returned value in a trigger to perform another function (ie turn on a pump when the differential value is >40)

any suggestions?

dave

[DaveL17]

This is perhaps a little tricky because either (or both) monitored value could change. Or put another way, if you only trigger on changes to state 1, the differential could exceed your target when state 2 changes--without triggering anything. I think the safest approach would be to create a trigger for each value you're monitoring and fire a small script when one or the other changes.

The Action for each trigger would run this Python script (which would need to be modified for your installation):

Code: Select all

dev = indigo.devices[DEV ID HERE]  # GhostXML device
state_1 = dev.states['STATE_NAME_HERE']
state_2 = dev.states['STATE_NAME_HERE']
var = indigo.variables[VAR ID HERE]  # result

if float(state_1) - float(state_2) > 40.0:
    indigo.variable.updateValue(var, 'True')
else:
    indigo.variable.updateValue(var, 'False')

This is untested, but it should be pretty close.

[bsp9493]

You are AMAZING... that's why I ask:)

Works like a charm!

I was looking at that in the indigo documentation, but yes, didn't think about monitoring both as you noted.

Thanx for the HELP!

dave

Access a custom device state

# get the device
dev = indigo.devices[23989834] # Some custom device
# access the state through the states property, use the key
# that's displayed in the Custom States tile on the main window
# when you have a custom device selected
print dev.states["someDeviceStateKey"]

# show all the device states (use unicode() to print special chars correctly):
print unicode(dev.states)

[DaveL17]

Glad that worked for you. I've been thinking about this a bit more and this will only work if A - B > 40 is True. If it's possible for B to be more than 40 units greater than A, it won't work.

Only you know your data well enough to know if it's a possibility (or even one that you want to account for), but this small revision should account for both cases.

Code: Select all

if abs(float(state_1) - float(state_2)) > 40.0:

[bsp9493]

yes, I did consider that...

it's actually a bit more complex than that, but what you sent me got me going, it's not pretty the way I implemented it and I"m sure there's a better way, but it works for now, and gives me some time to explore other options

basically 2 independent solar water systems

trigger1on
monitors and compares airTemp and poolTemp
if difference is greater than 12, it sets frontTempDiff to true, else to false

trigger1off
monitors the same
if the difference is less than 8, it sets frontTempDiff to false, else to true

when frontTempDiff = true, it turns on poolPump 1 to low
when frontTempDiff = false, it turns off poolPump1

now it gets more difficult - LOL

trigger2on
monitors and compares solarTemp and poolTemp
if difference is greater than 12, it sets backTempDiff to true, else to false

trigger2off
monitors the same
if the difference is less than 8, it sets backTempDiff to false, else to true

when backTempDiff is true, it turns on poolPump1 to low AND turns on circPump
when backTempDiff is false, it turns off poolPump1 AND turns off circPump



so, there is the case where frontTempDiff is >12 AND backTempDiff is <8 (or vise versa) which depending on when the triggers run would give a conflicting command to poolPump1

I guess in a nutshell, I want to turn something(s) ON when one or both systems are at >12 degrees temperature differential, and turn something(s) OFF when both systems are <8 degrees temperature diff

Again, I appreciate the help:)

d

[DaveL17]

That kind of logic begs for a plugin!

[kw123]

Can’t you use a simple trigger “any change of a variable” or device/state

Then a small python script that does your math.

Karl


Sent from my iPhone using Tapatalk

[bsp9493]

I'm sure there is a better way, but this seems to be working...

set a trigger on temperature change, then set a couple of the variables. Once the variables are set, have a second trigger for on and off of the specific devices (pump1 and solarCircPump)

Code: Select all

dev = indigo.devices[1422876465] # "Autelis - Status"
state_1 = dev.states['temp_airtemp']
state_2 = dev.states['temp_pooltemp']
state_3 = dev.states['temp_soltemp']
var = indigo.variables[466600928]  # solar true/false 
var2 = indigo.variables[600100007] # solar side true/false

if (float(state_1) - float(state_2) > 12.0) or (float(state_3) - float(state_2) > 12.0):
    indigo.variable.updateValue(var, 'true') # one OR both devices over 12 will turn on pump1

if (float(state_1) - float(state_2) < 8.0) and (float(state_3) - float(state_2) < 8.0):
	indigo.variable.updateValue(var, 'false') # BOTH devices less than 8  will turn off pump1

if float(state_3) - float(state_2) > 12.0:
    indigo.variable.updateValue(var2, 'true') # will turn on circpump

if float(state_3) - float(state_2) < 8.0:
	indigo.variable.updateValue(var2, 'false') # will turn off circpump





else:
    indigo.variable.updateValue(var, 'true') # tempdiff between 8 and 12 keep pumps running
    indigo.variable.updateValue(var2, 'true') # tempdiff between 8 and 12 keep pumps running

[DaveL17]

If it works and makes sense to you, it's a perfectly fine way to do it.

To make it even simpler, you could do the floats when you cast the variables, like this:

Code: Select all

dev = indigo.devices[1422876465] # "Autelis - Status"
state_1 = float(dev.states['temp_airtemp'])
state_2 = float(dev.states['temp_pooltemp'])
state_3 = float(dev.states['temp_soltemp'])
var = indigo.variables[466600928]  # solar true/false 
var2 = indigo.variables[600100007] # solar side true/false

if (state_1 - state_2 > 12.0) or (state_3 - state_2 > 12.0):
    indigo.variable.updateValue(var, 'true') # one OR both devices over 12 will turn on pump1

if (state_1 - state_2 < 8.0) and (state_3 - state_2 < 8.0):
   indigo.variable.updateValue(var, 'false') # BOTH devices less than 8  will turn off pump1

if state_3 - state_2 > 12.0:
    indigo.variable.updateValue(var2, 'true') # will turn on circpump

if state_3 - state_2 < 8.0:
   indigo.variable.updateValue(var2, 'false') # will turn off circpump

else:
    indigo.variable.updateValue(var, 'true') # tempdiff between 8 and 12 keep pumps running
    indigo.variable.updateValue(var2, 'true') # tempdiff between 8 and 12 keep pumps running

A second way would be to use descriptive variable names rather than the generic name like this (if I didn't screw it up):

Code: Select all

dev = indigo.devices[1422876465] # "Autelis - Status"
air_temp = float(dev.states['temp_airtemp'])
pool_temp = float(dev.states['temp_pooltemp'])
sol_temp = float(dev.states['temp_soltemp'])
solar_var = indigo.variables[466600928]  # solar true/false 
solar_side_var = indigo.variables[600100007] # solar side true/false

if (air_temp - pool_temp > 12.0) or (sol_temp - pool_temp > 12.0):
    indigo.variable.updateValue(solar_var, 'true') # one OR both devices over 12 will turn on pump1

if (air_temp - pool_temp < 8.0) and (sol_temp - pool_temp < 8.0):
   indigo.variable.updateValue(solar_var, 'false') # BOTH devices less than 8  will turn off pump1

if sol_temp - pool_temp > 12.0:
    indigo.variable.updateValue(solar_side_var, 'true') # will turn on circpump

if sol_temp - pool_temp < 8.0:
   indigo.variable.updateValue(solar_side_var, 'false') # will turn off circpump

else:
    indigo.variable.updateValue(solar_var, 'true') # tempdiff between 8 and 12 keep pumps running
    indigo.variable.updateValue(solar_side_var, 'true') # tempdiff between 8 and 12 keep pumps running

But those are a matter of taste. I find this is a good habit to get into, though, because I routinely look at old code and scratch my head while I try to remember what the hell I was doing.

[wideglidejrp]

I am attempting to pull stock price data from Alpha Advantage and then use the data for triggers which will adjust the color of an LED color strip on my office ceiling. I don't see how to get the actual data. My api query is:

https://www.alphavantage.co/query?funct ... R9DEIPRDTJ

I setup the device for UBER stock. If I choose the JSON option, it shows "Processing" but never changes. If I use XML option, it shows "Updated". The custom states I see are shown in the attached. What I don't see are the variables I expected which include open, high, low, close, volume. What am I doing wrong?

[DaveL17]

The output is definitely JSON. There must be something different in the output from when I last checked the API (as I said when we chatted, it's been a while). If the JSON tool is balking, then something in the data is causing the tool to hang. When I get a little time, I'll have a look at the data -- hopefully, I'll be able to find the thing that's causing the problem. Similar things have happened in the past and we've been able to tweak the model to work around them. No guarantees, though, I'm afraid.

[howartp]

Dave, thought I'd have a quick look at this, but I'm lost.

The JSON is intact on jsonlint.com checker, and looks simple enough.

Code: Select all

981      if self.finalDict is not None:
982          # Create the device states.
982.x        indigo.server.log("prestate")              #THIS WORKS
983          dev.stateListOrDisplayStateIdChanged()
983.x        indigo.server.log("poststate")              #THIS DOESN'T
984

Code: Select all

223      def getDeviceStateList(self, dev):
...
260          indigo.server.log("about to return")          #THIS WORKS
261          return state_list
262

This should give:

prestate
about to return
poststate

But for this data source, it only gives:

prestate
about to return

So the plugin is hanging/failing when trying to return state_list.

Another data source, to http://headers.jsontest.com, works fine.

Peter

[DaveL17]

Thanks Peter for having a go.

I'm still working on getting a matplotlib plugin bug fix tested (hang in there Bert!) but my initial suspicion is that many of the Alpha Vantage keys start with a character or series of characters that Indigo doesn't like. A quick test in the Python interpreter also says the AV JSON is valid. We may have something in the GhostXML code already that's just not working properly, or perhaps it will require a new routine to ensure that all prospective keys start with a character that Indigo likes.

Code: Select all

# Indigo shell:
>>> d = indigo.Dict()
>>> d['a'] = 'foo'
>>> d['1'] = 'bar'
Traceback (most recent call last):
  File "<console>", line 1, in <module>
StandardError: LowLevelBadParameterError -- illegal XML tag name character

# Python shell:
>>> d = dict()
>>> d['a'] = 'foo'
>>> d['1'] = 'bar'
>>> print(d)
>>> {'a': 'foo', '1': 'bar'}

[howartp]

I did notice afterwards that this JSON is multilevel.

Data begins at JSON[‘headerinfo’][‘key’] = value (in pseudocode), but I’m sure you’ve got handling of that in the plugin already?


Sent from my iPhone using Tapatalk Pro

[DaveL17]

I *think* multilevel should be okay. That's from memory, however.

It also goes without saying....more robust exception handling is needed.