Recent Posts

Pages: [1] 2 3 ... 10
1
Squeezebox Plugin / Squeezebox Plugin UI7
« Last post by jeubanks on February 17, 2018, 11:13:31 pm »
The squeezebox plugin doesn't seem to be working with UI7.  There's another thread on this but it's really old.  Any updates on getting this working again?  Or is this abandoned?
2
Blinds & Window Covering Control / Re: Ventilation window Control
« Last post by Tillsy on February 17, 2018, 09:33:47 pm »
Agreed - it's only 6A so a dual-light switch would be fine, but you could go a dual-relay if you wanted to be absolutely sure.
3
Blinds & Window Covering Control / Re: Ventilation window Control
« Last post by rafale77 on February 17, 2018, 09:17:48 pm »
Looks like it is passing 220V AC. A standard Zwave light switch won't work?
4
Lock, Motion & Security Control / Re: Skybell integration
« Last post by rafale77 on February 17, 2018, 09:14:31 pm »
+1 on interest for Skybell integration
5
I have been going for months without this problem. The big factor is to not have the vera reload luup right at the time the token is changing. The API changes the token on a regular basis. For example if you load a config from backup on your vera, you are very likely to have renew your token.
I have been able to stabilize the vera enough to go weeks between a luup restart by moving a lot of my plugins and scenes/automation to Openluup. You can track the reboots by installing the system monitor plugin and set it to send a notification every time luup reloads.
6
The Vera is likely rebooting without your knowledge. Mine still does it from time to time for reasons I haven't determined as of yet. It was doing it several times a day and that appeared to be caused by the ERGY plugin (that is installed by default). All it takes is one reboot at the wrong time. Hope you get this ironed out before you get too frustrated. I haven't had to reauthorize in weeks...
7
Plugins & Plugin Development / Re: BroadLink Mark II plugin
« Last post by a-lurker on February 17, 2018, 08:33:12 pm »
Ver 0.53 uploaded to GitHub - see first post.
8
General / Re: Firmware version 1.7.3532 Upgrade
« Last post by MtView on February 17, 2018, 08:21:07 pm »
I had to have customer care dial in and do this upgrade because it bricked when I did it by myself. 

Once it was done I did a restore and it didn't look like everything came back until I power cycled the plus.  You could also try logging out and in.  If that fails I would call Customer Care.  You shouldn't have to rename everything if it's all working correctly.
9
Video Camera Control / Re: Hikvision Cameras with motion sensor enabled
« Last post by jimmyz on February 17, 2018, 08:05:12 pm »
I have a Laview NVR. To get full streaming (will only work with the mobile app) you need to change the streaming option to
rtsp,rtsp,:8554/PSIA/streaming/channels/101
the next camera would be 102 etc
hope that helps
10
openLuup / Re: Run-Away 'Controller did not respond' message
« Last post by kartcon on February 17, 2018, 06:27:29 pm »
AK,

Thanks for the feedback. You are correct, openLuup was NOT running. But.... I did learn a couple valuable lessons from this.

1) On my system it takes a solid 90 seconds for openLuup to load and be ready. I clearly did not recognize this until this event occurred. Im not sure why it takes this much time, but it does.
2) As a very novice RPI user, I continue to learn every day. Some days i go forward, other I go backward. But thankfully this forum is here to help.

My typical startup procedure was this (in Terminal):
Code: [Select]
cd /home/pi/ect/cmh-ludl
/home/pi/ect/cmh-ludl/openLuup_reload
In each case this is what I would see:
Code: [Select]
pi@raspberrypi:~ $ cd /home/pi/ect/cmh-ludl
pi@raspberrypi:~/ect/cmh-ludl $ /home/pi/ect/cmh-ludl/openLuup_reload
cp: cannot stat ?/www/cmh/skins/default/icons/MString.png?: No such file or directory

In addition, the terminal app seems to hang on this command, meaning that the typical "pi@raspberrypi:~/ect/cmh-ludl $" prompt not does display after I execute the above command.

Recently I have learned how to update the rc.local file using this command:
Code: [Select]
sudo cp -i /home/pi/Documents/rc.local /etc/rc.local

My edited rc.local looks like this:
Code: [Select]
#!/bin/sh -e
#
# rc.local
#
# This script is executed at the end of each multiuser runlevel.
# Make sure that the script will "exit 0" on success or any other
# value on error.
#
# In order to enable or disable this script just change the execution
# bits.
#
# By default this script does nothing.

# Print the IP address
_IP=$(hostname -I) || true
if [ "$_IP" ]; then
  printf "My IP address is %s\n" "$_IP"
fi

sleep 20
cd /etc/cmh-ludl
./openLuup_reload

exit 0

However I am not sure if the path is defined correctly. Should it read :
cd  /home/pi/etc/cmh-ludl
OR
cd /etc/cmh-ludl

Again, the terminal app does seem to hang after this, and that MAY be part of the 90+ second delay in openLuup running and becoming responsive. I am beginning to think that once Terminal see's the "?/www/cmh/skins/default/icons/MString.png?: No such file or directory" it takes up to 90 seconds for the app to timeout before becoming active again, thus the delay in my startup. Of course this is my rookie interpretation of what might be happening.

Lastly, I can not get my system to respond with any message like "Another copy is running" once I am SURE that openLuup is running. Maybe it is because of the error that the startup generates, or maybe I am simply not waiting long enough for the message to pop up.

So to summarize, I was able to get openLuup running again, but I still am not certain that it is starting completely and successfully, due to the error generated and the long delay before the site will load successfully.

Any suggestions would be appreciated. Thank you.

Pages: [1] 2 3 ... 10