So I just saw in an old post from another thread that cybrmage had a heart attack and was not doing well many months ago. 
I hope he is ok but am guessing he wonāt be responding sadly. Just wondering if anyone out there is still using this with a non pro bridge and if it is working for them. I am trying to recreate this but am not getting the same data that he did which makes me wonder if Lutron changed how it works and this broke it. Any info would be great. Thanks!
Nate
This plugin is absolutely spectacular ;D
The only thing that I could possible see to add to this that would be useful is to be able to detect the light dimmer levels when they change (IE: use to detect when the actual Caseta dimmer control is selected to āonā or āoffā or detect when light level reaches 100%). This would make the one scene that I have run into so far better to program and that is the z-wave switch the controls the light over the sink to come on when the kitchen lights go to 100%. I can see other things as well. Now, if this would cause a serious performance degradation then ā no.
Having some trouble with the newest version. I noticed my lutron scenes changed number in veraās devices after installing, but overall this isnāt a huge issue. However, after running for a little while, I get a Startup Lua Failed notice. I turned on debug and included anything around the word failed that I found in the log around the time that the startup failed notice appeared. I had noticed things would eventually stop working after 2-3 days before, but I had Vera restart daily, and the issues had gone away. But this has been happening frequently since I updated a few days ago. Thoughts?
Edit: I have a Smartbridge Pro 2. Also, the Lutron scenes keep getting removed after every error, and renumbered higher in the vera numbering scheme.
Your log is MISSING huge chunks of timeā¦ So, canāt really tell what is going onā¦
Except, it is specifically showning that it is unable to connect to the bridgeā¦ That, along with your statement that it will run for several days, points to the possibility that your router is changing the IP Address of the bridgeā¦
Make sure that you have configured your router to āreserveā an IP Address for the smartbridge.
Then, reload the LuaUPnP engine, and if the error happens again, post the logs againā¦ but make sure you go back far enough that you get the plugin startup line ( the one that states āCaseta Connect Automation Gateway v1.63 - ************** STARTING **************ā)
Sorry about that. Attached is a complete log from start up to failure (only modification was to XXXX out some password stuff for another plugin). The only thing I did to precipitate the failure (within a few minutes) was attempt to add a lutron scene to a vera scene, prompting a LUA startup message in vera, and its subsequent startup LUA failed message. The IP address is manually set to both the vera and the lutron hub on the router (statically at 192.168.2.49 and .53 respectively).
I donāt know if it matters, but there is one switch which is the newer PD-5NE-WH lutron dimmer that I added about 1-2 weeks ago. The rest are the older model dimmers (pro and non-pro), pico remotes, and wall switches.
EDIT: Also, when leaving this alone, it looks like the plugin eventually restarted, but then the lutron scenes never got added back, but individual light control works fine with their original associated vera device numbers still associated with them. I changed the log file attached to include everything, including this later part.
You have MULTIPLE issuesā¦
Excluding the plugin and Z-Wave issuesā¦
Over the several restarts shown in the logs, the smartbridge failing to respond to the plugin when it tries to connect to the LIP server, causing the plugin show as failed. This is NOT the plugin failing, this is the bridge failing to allow a connection, which prevents the plugin from operating.
The few times that the bridge does allow a connection to the LIP server, the plugin appears to be operating as intended.
The other issue is that the smartbridge is reporting various configuration sections inconsistentlyā¦ This is causing the plugin to create the devices for the Lutron scenes, which requires a restartā¦ the bridge then fails to report the scenes, causing the plugin to delete the devices for the Lutron scenes, which requires a restartā¦ which becomes a restart loop until the same data is reported in two consecutive restartsā¦ which then allows the plugin to operate normallyā¦ Until the plugin issue forces a restartā¦
You need to get BOTH your Vera and your Lutron smartbridge into a consistent stateā¦
First step is to unplug BOTH the Vera and the Smartbridge and allow them to remain off for several minutesā¦ then plug them in, and retestā¦
Wow, that bad, huhā¦
I greatly appreciate your help trying to narrow down the many issues on my device, especially since it appears unrelated to your plugin specifically. I had tried rebooting both devices in my attempts at fixing things, but not for a sustained period of time for more than 5 min or so. I went ahead and did as you asked, unplugging both for 15 minutes and replugging in. Prior to that, I had deleted the Harmony Hub plugin, as my use for it on vera was minimal.
Thus far, even when changing scene information requiring a reloading of the Lua plugins, it appears everything works correctly. I havenāt yet received an error with the plugin loading, and the lutron scenes have a new, but more importantly, stable, number that hasnāt yet changed. They persisted after a restart as well, so things are looking promising.
Weāll see how everything goes for a few days, and Iāll report back if the issues return, but at least in my 30 minutes of testing, things are MUCH more stable than they were prior to your help. I donāt know what is going on with the Z-wave devices, but at least from a usability point of view, theyāre still working well. Thanks again for the troubleshooting, and for making such an amazing plugin!
The āfailed plugin downloadā is one of the hardest problems to find unless you look at the verbose logsā¦ and it has a HUGE impact on the systems usabilityā¦ A restart every 10 minutes for no obvious reason is definately a big reliability killer.
That indicates that everything is goodā¦ The Smartbridge has a tendancy to go wonky if you add/remove a lot of devices/scenes at once or if the bridge is near its device limitā¦ My recommendationā¦ If you add/remove devices/scenes on the smartbridge, power cycle the smartbridege before you reload the LuaUPnP engine to sync the new configuration.
The Z-Wave issues could be a simple matter of the Z-Wave dongle (built into the Vera) having a hard time coping with interference, or acting wonky dur to a power surgeā¦ or Vera not able to talk to it due to memory issuesā¦ The abort errors MAY indicate that you have a device that Vera is having trouble communicating withā¦ It could be too far away, or in a location where the signal is obstructed or it could be a failing or marginal device. As long as your Vera is able to control and communicate with the Z-Wave devices without a significant delay, itās usually not something to be overly concerned with.
Iām glad things are running smoother for you nowā¦
Hello! Great work on the plugins. Iām new to the forums and to Vera in general, but I think perhaps I found a bug in the Caseta plugin.
I have a non-pro Smart Bridge. When switch the lights on/off from the wall panel or the PICO, I would expect the Vera dashboard/panel to update showing the change. Iāve waited a number of minutes and it doesnāt refresh. However, if I restart the Vera Lite, then it grabs the correct percentage and on/off status.
Looking at the logs I notice the following in red (in bold):
01 02/05/17 21:35:09.476 IOPort::Connect connect -1 lutron.broker.xively.com:1883 <0x2d789680>
50 02/05/17 21:35:46.106 luup_log:11: MQTT.client:handler(): PINGREQ <0x2c389680>
01 02/05/17 21:36:16.059 LuaInterface::CallFunction_Timer device 11 MQTT_KeepAlive took 30 seconds <0x2c389680>
When I check port 1883 on lutron.broker.xively.com, it fails, but port 8883 connects. (I found port 8883 while sniffing traffic from my iPhone Lutron app.)
$ telnet lutron.broker.xively.com 8883
Trying 52.23.255.236...
Connected to lutron.broker.xively.com.
Iām not sure what the āconnect -1ā part of the above log means, but does it mean that it cannot connect? Might the port have changed to 8883? Is there a way to change that port number and try it?
Many thanks!
Hello,
I picked up a Pro2 bridge and itās working well. Iām having a couple of issues with 2 of my three remotes not sending certain commands Scene back to Vera.
Iāve tried replacing the remote batteries. Is there an easy way to debug this to see whatās happening?
I would like to see if the plugin is seeing the button presses as expected.
Please let me know next steps.
UPDATE - Remote seems to be working fine. It just wonāt trigger 2 of 6 scenesā¦?
What could be causing the system to trigger some but not all scenes?
In my example, I have an IR blaster connected to VERA over IP that controls my TV.
Vol+ / Vol - / Mute Work but TV On / TV Off donāt work.
All of these sceneās work perfectly when I trigger them via the Vera app or vera web gui.
Is there a naming / character limitation in the Scene names? I have a one other Pico remote that works perfectly for another room and when I sawp them I get the same result.
Note sure where to go to start troubleshooting. I have logging enabled on Vera - Would the log explain whatās happening?
Any help would be greatly appreciated.
Thanks
Would it be possible to update the subcategory of the device that gets created for the Caseta On/Off switch (PD-5WS-DV-WH)? Right now they are getting created with subcategory 0 which causes them to not be included in the lights for the Turn All On/Turn All Off shortcut. Manually changing them to subcategory 1 (Interior) works.
Could someone please provide me with the proper Luup code to activate a Caseta Scene via the Caseta Connect plugin?? I would like to use luup to check the status of a light sensor, run one Caseta scene if the sensor is above 15 lux, and run a different Caseta scene if the sensor is below 15 lux. For the life of me I canāt figure out the correct syntax (I am new at this).
Iāve tried:
(because Caseta scenes show as SwitchPower1 in the device log)
local dark_scene = 73
luup.call_action("urn:upnp-org:serviceId:SwitchPower1","SetTarget",{newTargetValue="1"},dark_scene)
(because Iām trying to run a scene)
local dark_scene = 73
luup.call_action("urn:micasaverde-com:serviceId:HomeAutomationGateway1","RunScene",{ SceneNum=dark_scene },0)
(because Iām trying to run a Caseta scene)
local dark_scene = 73
luup.call_action("urn:caseta-com:serviceId:CasetaScene1","RunScene",{SceneNum=dark_scene},0)
No luckā¦ help please!
Relaying back some information since I last posted about scenes being renumbered and all sorts of vera problems. Well, I still was having some issues (although better than before), so I fully reset the Vera and the Lutron smartbridge, and readded every device.
Things seem maybe slightly better, but I was still having issues with the smartbridge not communicating with the plugin after about 3-4 days, but it seemed that the telnet part of the Lutron smartbridge stopped communicating. Putting the Lutron hub on a timer to reboot itself daily appeared to fix most of the issues with the exception of one.
I still occasionally have problems with the lutron scenes renumbering themselves in the Vera, which messes with my vera scenes. I havenāt added or removed anything from the smartbridge or vera, yet this appears to occur on a weekly basis roughly. I donāt know if this is because I have 48 Lutron devices, since as you mentioned, the hub appears to go a bit wonky as you near the 50 device limit.
As a work around, I stopped using Lutron scenes in any of the vera scenes, but could there be an option placed to disable the plugin from loading vera scenes, just so theyāre not recreated randomly? Thanks!
Any clue as of why altui complains about mdns_devices function in openluup?
stack:TypeError: mdns_devices.split is not a function
at selectBridgeDevice (:86:36)
at eval (eval at _deviceDrawControlPanelJSTab (http://xxx.xxx.xxx.xxx:3480/J_ALTUI_uimgr.js:2893:17), :1:1)
at _deviceDrawControlPanelJSTab (http://xxx.xxx.xxx.xxx:3480/J_ALTUI_uimgr.js:2893:17)
at _deviceDrawControlPanelOneTabContent (http://xxx.xxx.xxx.xxx:3480/J_ALTUI_uimgr.js:3413:8)
at _displayActiveDeviceTab (http://xxx.xxx.xxx.xxx:3480/J_ALTUI_uimgr.js:3440:4)
at HTMLAnchorElement. (http://xxx.xxx.xxx.xxx:3480/J_ALTUI_uimgr.js:6348:4)
at HTMLDivElement.dispatch (http://xxx.xxx.xxx.xxx:3480/icons/localCDN/jquery.min.js:3:7537)
at HTMLDivElement.r.handle (http://xxx.xxx.xxx.xxx:3480/icons/localCDN/jquery.min.js:3:5620)
at Object.trigger (http://xxx.xxx.xxx.xxx:3480/icons/localCDN/jquery.min.js:4:4818)
at HTMLAnchorElement. (http://xxx.xxx.xxx.xxx:3480/icons/localCDN/jquery.min.js:4:5328)
It also complains here:
2017-06-25 14:49:14.396 openLuup.context_switch:: ERROR: [string "[231] I_CasetaConnect.xml"]:1392: attempt to perform arithmetic on global 'init_year' (a nil value)stack traceback:
./openLuup/scheduler.lua:128: in function <./openLuup/scheduler.lua:125>
(tail call): ?
./openLuup/scheduler.lua:238: in function 'dispatch'
./openLuup/scheduler.lua:705: in function 'task_callbacks'
./openLuup/scheduler.lua:1084: in function 'start'
openLuup/init.lua:322: in main chunk
[C]: ?Found a little bugā¦
The app is trying to read the openluup version as ārevisionDateā but it is defined as āVERSIONā . after modifying āL_CasetaConnect.luaā line 1390 from:
INITversion = self:shellExecute('head -n 3 /etc/cmh-ludl/openLuup/init.lua |grep -e "revisionDate ="')
to this:
INITversion = self:shellExecute('head -n 3 /etc/cmh-ludl/openLuup/init.lua |grep -e "VERSION "')
and this:
IOversion = self:shellExecute('head -n 3 /etc/cmh-ludl/openLuup/io.lua |grep -e "revisionDate ="')
to this:
IOversion = self:shellExecute('head -n 3 /etc/cmh-ludl/openLuup/io.lua |grep -e "VERSION "')
everything started workingā¦
Hello,
I have a Vera Plus UI7 with the Caseta Connect 1.63 plugin with no other devices configured.
I am unable to have the plugin discover my Caseta Pro hub.
Please see the log entry below.
Thank you!
I am running UI17 with 1.73015. Everything was great running the Caseta app on version 1.63. Now that 1.65 has automatically updated I get the error āFailed to load bridge configā Running the Pro Bridge
Any suggestions?
new version
v1.75 (Version ID: 34472) September 12, 2017
ā added - LEAP service monitor to provide real-time status updates to smartbridge (non-pro) in place of MQTT
ā changed - removed obsolete embedded MQTT client (Lutron move the MQTT data to a secure server - The Vera IO model is not compatible with the requirements for TLS encapsulation)
** NOTE ** - The Lutron account credentials that were required to use MQTT are no longer required. There credentials are now only used for bridge discovery.
Back up and running. Thank you !
1.75 keeps dropping connection between vera and pro bridge. I have turned off auto update and restored to 1.65 to keep working. Any idea why 1.75 caused this? iām using vera pro UI17 with 1.73015.
Best Home Automation shopping experience. Shop at Ezlo!
Ā© 2024 Ezlo Innovation, All Rights Reserved. Terms of Use | Privacy Policy | Forum Rules