This plugin integrates a Connected By TCP LED lighting gateway with a Vera controller. Once a device for the gateway is created, the plugin in turn creates child devices (of type Dimming or SwitchPower, as appropriate) for each connected bulb. Since the bulbs are created as standard devices, they are available for control via scenes, mobile apps, etc.
Only weirdly I’m fighting is the resulting automatically created lights won’t stay in their assigned rooms. That is certainly not a big problem. I’ll look at the code later this week and see if I can spot anything.
Thanks for the feedback and taking the time to try it out.
I’ve seen some of the same flakiness with the room assignments, especially when defining scenes. Oddly enough, the room numbers look right in the device properties and a UI refresh seems to put things right. Since I didn’t find any documentation on how to programatically assign a device’s room, I simply tried the obvious and assigned the devices’s room and roomnum properties to the room number of the matching room. My guess is that there may be some other internal data structure that caches this info and my assignments don’t go through the same code path as making the assignments through the UI.
In case there are future updates, (I can see 0.1 & 0.2) I just wanted to suggest the idea of maintaining one overall thread for your plugin going forward, that way we can keep track of the changes/updates etc. and people can also watch just one thread.
Many developers on this forum maintain their very first post as the version control list and also to store the latest files to download too. It works very well.
I don’t mind the suggestion at all and that was actually my original intent , but being a nube, I couldn’t figure out how to modify the thread topic name separately from the message subject name.
You should be able to click on the modify option that’s visible to you on any post you make. You can then edit the subject or the body. If you edit the subject line of your first post it will be reflected on the forum boards,
This version provides better handling of unknown room names, i.e room names from the Connected By TCP Gateway that do not match Vera room names. The plugin will now only update the room name if a match is found. Previous versions erroneously set the room number to zero in such a case.
great work on this plugin. I think me being able to write a plugin - for anything - is a long, long ways off in the future, but I’m still glad my initial discovery was helpful to this great community. What’s the saying about even a blind squirrel finding a nut…?
great work on this plugin. I think me being able to write a plugin - for anything - is a long, long ways off in the future, but I’m still glad my initial discovery was helpful to this great community. What’s the saying about even a blind squirrel finding a nut…? :)[/quote]
Thanks for your kind words.
A previous boss of mine liked to emphasize that “the team is smart”. I think that translates directly to this forum, where “the community is smart”. We collectively get a lot more done together than if everyone tried to sort everything out from scratch.
I believe this version is ready for submission to the app store, which will have the side benefit of greatly simplifying the installation process. If you use this plugin, it would be greatly appreciated if you could reply to this thread stating whether or not you think this plugin is ready for the app store. If you don’t think it is, please let me know why and I’ll endeavor to fix it.
[quote=“maddingo50, post:13, topic:179548”]I am having trouble getting this to work. I entered the TCP lighting ip but still get:
"Sync to the gateway and configure lights - Gateway ip must be specified in Advanced tabSyncGateway Errors:
"[/quote]
Hi there,
Sorry I didn’t see your post earlier. Do you know how to check your log file? If so, let me know if you see any entries containing the text “TCPLighting”.
[quote=“ecsherwo, post:16, topic:179548”]The only thing I changed was to Configure “remote access” in the TCP app.
Is that required in order for the plugin to work? I would not have thought so, since it looks to be making local calls to the TCP-Gateway.[/quote]
I had Remote Access on prior to developing/testing the plugin, and resetting remote access from the app didn’t change anything. However, it’s quite possible that enabling remote access has the side effect of enabling the HTTP interface that the plugin uses. I’ll add this as a “thing to try” on the documentation for the plugin.
I find that lights take a while to change and that it’s a noticeably serialize process (about 0.5 seconds for each light). This is particularly noticeable when a scene triggers several lights.
Anyone else see this behavior when controlling more than one TCP light at a time? It’s pretty annoying.
I’ve noted some of the same delays, and suspect it’s a mix of a few things:
[ul][li]The mesh nature of the JenNet-IP stuff that the TCPi lights use. It seems that there is sometimes a response delay for the lights furthest from the gateway.[/li]
[li]There does seem to be some lag involved with scene processing.[/li]
[li]A potential lag by going through the plugin, but my guess is that this is pretty minimal. In my testing of the plugin, the direct on/off stuff for the single light closest to the gateway is generally quite fast.[/li][/ul]
If I get some free time, I may run some experiments over the weekend to see if I can sort out the contribution to the overall delays for each of the above.
[quote=“androbot, post:18, topic:179548”]I find that lights take a while to change and that it’s a noticeably serialize process (about 0.5 seconds for each light). This is particularly noticeable when a scene triggers several lights.
Anyone else see this behavior when controlling more than one TCP light at a time? It’s pretty annoying.[/quote]
I’ve taken a look at this, and it turns out that the plugin code does cause some of the delay. When you use the plugin to turn a light on/off or change the dimming level, the plugin basically does three things:
[ol][li]It performs the requested action (on/off/dimming level)[/li]
[li]It polls the gateway to get the latest status of the bulbs[/li]
[li]It updates the settings of the device to match that reported back from the gateway[/li][/ol]
It’s these last two steps that create some of the delay when you control multiple bulbs through a scene. It’s also why it not apparent when controlling one bulb - the extra processing takes place after the bulb’s state has changed.
I have a few ideas how I might be able to trim off some this time, but I’m not 100% pleased with any of them, so if you’ll indulge me, I’m going to think about this one a bit. I could of course skip the polling step and simply assume that the command sent to the gateway executed as expected, and thus update the device state to reflect the requested action, but this strikes me as far too optimistic
A little experimentation also showed that this did not account for all of the delay. Even when I stripped out those last two steps, there was still a delay, albeit shorter. This remaining delay I suspect is part of the way scenes are executed.
