Indigo Domotics

gregjsmith wrote:

I double clicked on the file and indigo popped up and gave me the option of downgrading. I did the downgrade and it installed without issue.

Oh. I know what happened then. I changed the version number, to the proper version umber. I forgot to do that with the initial beta....

I usually manually install the plug in's.... So I didn't think about that method...

I was getting errors that the device could not be updated unless its part of a switchboard group. Also it doesn't appear my applescript asking what the on state is will work.

gregjsmith wrote:

I was getting errors that the device could not be updated unless its part of a switchboard group. Also it doesn't appear my applescript asking what the on state is will work.

Can you please cut and paste the log entries in question?

According to Matt & Jay, Applescript doesn't have access to device states.... But Indigo triggers certainly do... So the most obvious work around would be the Action Collection plugin to copy the state to a variable that you can test with Applescript....

What are you trying to do in Applescript? It might be something that I can generalize and make available via the plugin directly...?

That's one of the the dangers of using onState as a custom device state name - it's likely to cause confusion for users. I'd shy away from using any of the built-in device property names as state names in custom devices.

jay wrote:

That's one of the the dangers of using onState as a custom device state name - it's likely to cause confusion for users. I'd shy away from using any of the built-in device property names as state names in custom devices.

I partially agree, but having a known "onState" state that tracks the on status of the device, allows any plugin programmer access a known state variable...

Yes, Applescript can't access it, but that's a limitation of the software...

I certainly can rename the onState state to something else, but how does that solve the user's problem? It really doesn't.... If I called it XyzState, they still would need to use Action Collection, or have the plugin automatically export the state to a variable...

In my opinion, the better solution, is to help ensure people realize that custom Devices states are not accessible through Applescript.

But I'm certainly willing to rename the onState state.... I just don't see how that will help...

IMO it will keep users from confusing:

Code: Select all

someDevice.onState

with:

Code: Select all

someDevice.states['onState']

If you want to attempt some consistency, then use onOffState as your state name. Relay and dimmer devices use that state name in their states dictionary and they mirror what the onState property of those device types returns. It's slightly dangerous because we're going to allow plugins to add states to devices that implement one of the built-in types (relay/dimmer) - so if you define a state called onOffState then at the moment the consequences are unknown (though we may just ignore it). But it does offer the consistency that you mention without confusing the property of a built-in device with the state.

Hi there,

I managed to install the new plugin that replaces the security script, I now do see the security sensor being detected in the event log of indigo 5, but
I can't figure out how I can pick up this signal and make it change a variable.

I enclosed the part of the event log. As you can see it detects a door switch with id 69. I defined this doorswitch as a device called "test sensor" and gave it the X10 ID 69.
The log mentions "Testsensor [1202179182] not been assigned a Switchboard Group." I don't know how to do that.

Someone has a clue ?

regards,

Paul

6 jan. 2012 11:39:44
Received RF security command sensor alert (min delay) (ID 69)
Switchboard Debug x10CommandReceived:
address :
cmdSuccess : True
cmdType : sec
secCodeId : 69
secFunc : sensor alert (min delay)
Switchboard Debug No X10 Address was received (but it might have a Security ID)
Switchboard Error Testsensor [1202179182] not been assigned a Switchboard Group.
Switchboard Debug Zone None, Device 1202179182
Switchboard Debug OPEN
Switchboard _Open
Received RF security command sensor normal (min delay) (ID 69)
Switchboard Debug x10CommandReceived:
address :
cmdSuccess : True
cmdType : sec
secCodeId : 69
secFunc : sensor normal (min delay)
Switchboard Debug No X10 Address was received (but it might have a Security ID)
Switchboard Error Testsensor [1202179182] not been assigned a Switchboard Group.
Switchboard Debug Zone None, Device 1202179182
Switchboard Debug CLOSED
Switchboard _Closed

boekweg wrote:

Hi there,

I managed to install the new plugin that replaces the security script, I now do see the security sensor being detected in the event log of indigo 5, but
I can't figure out how I can pick up this signal and make it change a variable.

I enclosed the part of the event log. As you can see it detects a door switch with id 69. I defined this doorswitch as a device called "test sensor" and gave it the X10 ID 69.
The log mentions "Testsensor [1202179182] not been assigned a Switchboard Group." I don't know how to do that.

Paul,

The new switchboard plugin should eliminate the majority of the need for variables....

Switchboard will handle most of the dispatching of tasks, based on the Monitored Device Groups... Devices are assigned to a group, generally based on a common task. For example, Exterior Doors... But the Monitored Devices groups, can be any conceptual idea... It's just an easy way to organize the task, and not have to re-enter the same data multiple times...

To make a Monitored Device Group, make a new device:

Type - Plugin
Plugin - Switchboard
Model - Monitored Device Group

Between the Timed Device Support, and Action Group Support, there is very little that needs to be controlled by variables...

Now, for now at least, could you give me an idea on where you need a variable?

Keep in mind, you can trigger off the state of the device, which in most cases would replace the variables that you are use to in v4...

Hi Benjamin,

Thank you for your instruction. It works now!
I'm using variables for detecting the state of a door or window. I now managed to have the state of the device
displayed in the GUI, so in this case I do not need a variable anymore. The only reason I still would like to have variables
is that I can not choose (I think) what the displayed text in the GUI is when a state of a door sensor changes. In Dutch I can not choose the phrase " dicht" which means closed.
I also use variables for determination of being away or at home for instance.

Thanks a lot for this!

Regards Paul

boekweg wrote:

Hi Benjamin,

Thank you for your instruction. It works now!
I'm using variables for detecting the state of a door or window. I now managed to have the state of the device
displayed in the GUI, so in this case I do not need a variable anymore. The only reason I still would like to have variables
is that I can not choose (I think) what the displayed text in the GUI is when a state of a door sensor changes. In Dutch I can not choose the phrase " dicht" which means closed.
I also use variables for determination of being away or at home for instance.

Contact me with the translations, and I'll add a language feature to the plugin....

Anyone else that would like to assist with that, please do so as well...

Anyone that has suggestions on languages to support, please let me know...
And maybe I'll even dust off the Klingon Language guide I have in the basement...

I found another way, and keep using the variables as well. Thanks for the support. The plugin works well !
I don't think I have explored all possibilities yet, that will come in time.

Regards Paul

boekweg wrote:

I found another way, and keep using the variables as well. Thanks for the support. The plugin works well !
I don't think I have explored all possibilities yet, that will come in time.

Paul,

Can you share the technique you decided to use? It certainly might give me some ideas...

Certainly Benjamin:

When I was using 4.03 script with Indigo 4 I was able to define my own variable name and therefore I could use all sorts of dutch words.
In your plugin with Indigo 5 the state is predefined and for now not changeable.
What I did to be able to display the dutch variables on my UI I use your plugin to capture the door sensor and then I defined a trigger within Indigo 5 with the following settings:
******

Device state changed
Device: "doorsensorname"
the last X10 Command Received
becomes Not Equal to " sensor normal (min delay)" / which is the "zero" state of the door sensor

Condition: always

Actions:
type: modify variable
Variable: "variable UI name"
set to: "whatever dutch word I want to use"
*******
Hope this helps.

Paul

Switchboard, New Beta pending shortly....

I am finishing up on some changes with Switchboard... and I expect to release v0.55 within a day or so.

Changes

• v0.55 - WIP - Third Public Release (Beta 3)
⁃ Fixed warning message "%s [%s] not been assigned a Switchboard Group", to say "… not been assigned a Monitored Device Group", due to the change from "Switchboard group" to "Monitored Device Group".
⁃ Made more changes to the X10 code, to make the X10 devices mostly independent of the Device Groups
⁃ Finished creating the Security Center Device
⁃ This tracks security related states
⁃ Panic
⁃ Alarm Status (Armed, Disarmed)
⁃ It will oversee all X10 traffic, and if a Security Center device exists, it will keep those states up to date, depending on the X10 traffic.

• v0.51 - 1/4/2011 - Second Public Release (Beta 2)
⁃ Started work on Security Control device (not fully functional yet)
⁃ Fixed Virtual state display. The state column will now report "Opened", "Closed", etc.
⁃ Rewrote X10 code, to allow the device to have a state, even when it was not in a monitored group.
⁃ Revised the states for the X10 devices.
⁃ If you used v0.50, you will need to go into each devices's configuration, and re-save the configuration. This should update the available states to v0.51.

Here's the link to v0.55:

http://dl.dropbox.com/u/241415/Switchbo ... 0v0.55.zip

Everyone that uses it, please leave some feedback. Even, it works great, helps to some extent. Overall, I am surprised at the lack of feedback I have received...

I could understand the lack, if this was an exact clone of the security script, but I was expecting at least some feedback from ex-security script users... (Both Positive and negative feedback, but I expected some...)

What features do you think should be added? What features don't make sense to you?

- Ben

bschollnick2 wrote:

Switchboard, New Beta pending shortly....

I am finishing up on some changes with Switchboard... and I expect to release v0.55 within a day or so.

Changes

• v0.55 - WIP - Third Public Release (Beta 3)
⁃ Fixed warning message "%s [%s] not been assigned a Switchboard Group", to say "… not been assigned a Monitored Device Group", due to the change from "Switchboard group" to "Monitored Device Group".
⁃ Made more changes to the X10 code, to make the X10 devices mostly independent of the Device Groups
⁃ Finished creating the Security Center Device
⁃ This tracks security related states
⁃ Panic
⁃ Alarm Status (Armed, Disarmed)
⁃ It will oversee all X10 traffic, and if a Security Center device exists, it will keep those states up to date, depending on the X10 traffic.

• v0.51 - 1/4/2011 - Second Public Release (Beta 2)
⁃ Started work on Security Control device (not fully functional yet)
⁃ Fixed Virtual state display. The state column will now report "Opened", "Closed", etc.
⁃ Rewrote X10 code, to allow the device to have a state, even when it was not in a monitored group.
⁃ Revised the states for the X10 devices.
⁃ If you used v0.50, you will need to go into each devices's configuration, and re-save the configuration. This should update the available states to v0.51.