Screw Loose Dan

Kevin - In the install scripts you set up: update-alternatives --install /usr/bin/python python /usr/bin/python3.5 2 update-alternatives --install /usr/bin/python python /usr/bin/python2.7 1 And you mention: I'm trying to run a Polyglot node server Presence-Poly, which installs (via apt) an application "python-bluez". This application won't install/run without python2.7 set as the desired alternative. Will that cause an issue for the softconsole?

That gives me a lot of ideas and thoughts on what to start playing with!! My initial thought is to connect a an ambient light sensor to a GPIO pin on the RPi that is running Polyglot. There is a Polyglot GPIO node server already and I *think* they expose an MQTT service as well...hmmm. Lots to play with. Thanks!!

I just downloaded and started using the latest release. So far no issues. A thought for a feature request...I recently purchased a Google Home Hub display. It amazes me with it's screen dimming. It has an ambient light sensor and gets extremely dim in a dark room, but is still readable. And, obviously it gets brighter as needed. As I type all that out, it doesn't come across as nearly astounding as it actually is, it's really quite remarkable. Google did there homework. One of the thing I've struggled with on the softconsole is finding a sweet spot for the dim settings., especially for the bedroom unit. Having an ambient light sensor would be awesome, but I realize that might open a whole other can of worms. Instead, perhaps a time based feature for dimming? So in addition to DimLevel/BrightLevel, also a DimLevelLate/BrightLevelLate as well as two variables to set the time to use the additional Dim/Bright levels (LateStart/LateEnd). I know, easy for me to suggest, probably not as easy to implement. ? If you have any suggestions on what to look at, I could perhaps poke around. Anyway, you mentioned you would be travelling out of country for a few weeks. Enjoy your trip! Safe travels.

You guys talking about SSL certificate errors, reminded me we had some of this conversation before. I did get it to work (with a trusted "trusted" cert), but ultimately found the softconsole was not very useful. Let me know you you make out.

I installed the new Beta about 30 minutes ago, and not a single "ISY reported and immediately cleared error" has shown up in the softconsole logs. They were sporadic (best I could tell), but usually appear every 5-15 minutes. So, I believe it's resolved. Thanks!

Ah yes, I had missed that EVictory was having similar errors. Sorry about that. I just switched to the Beta and my initial test shows much less logging of errors. I do see lots of this, but haven't looked to see what the issue might be on the ISY/Polyglot side of things: 01-06-19 00:31:21 Sev: 4 ISY reported and immediately cleared error for node: n001_t198772770918 () (seq:-99/50) 01-06-19 00:31:24 Sev: 4 ISY reported and immediately cleared error for node: n002_controller () (seq:-99/123) 01-06-19 00:31:24 Sev: 4 ISY reported and immediately cleared error for node: n002_a407b6bccac1 () (seq:-99/125) 01-06-19 00:31:25 Sev: 4 ISY reported and immediately cleared error for node: n003_controller () (seq:-99/127) 01-06-19 00:31:25 Sev: 4 ISY reported and immediately cleared error for node: n003_d_0 () (seq:-99/132) 01-06-19 00:31:26 Sev: 4 ISY reported and immediately cleared error for node: n003_d_2 () (seq:-99/135) 01-06-19 00:31:26 Sev: 4 ISY reported and immediately cleared error for node: n003_d_3 () (seq:-99/138) 01-06-19 00:31:27 Sev: 4 ISY reported and immediately cleared error for node: n003_d_4 () (seq:-99/146) Regarding the query on battery devices, I concur comm issues are rarely seen with battery devices, but it just stumbled upon it last week. As long as it's a fire and forget (like the 3 AM query), not a big deal at all. Just didn't want a tight loop or anything. Thanks again!

FYI - This sounds like a good idea (I currently use a program to do this for my garage door opener), but the thought I had when I read this was regarding battery devices. Do you handle them differently? Battery devices (motion detectors, leak sensors, door contact sensors, etc) won't respond to a query normally. Might not matter, just thought I'd mention.

I recently upgraded to ISY firmware 5.0.14 (it was fairly painless for me) so I could play with node servers/Polyglot. Today, I finally got around to updating my softconsole to the latest version. I checked the softconsole logs after the upgrade and I realized things had run a muck... I've been ignoring the error notification dot for so long now, I probably should have looked sooner as it's been filling my logs. Anyway, this is a sample of the errors I'm seeing: 01-05-19 15:07:12 Sev: 4 Problem with processing node: Ecobee Controller Address: n001_controller Pnode: n001_controller 128/true/'unknown' 01-05-19 15:07:13 Sev: 4 Problem with processing node: Ecobee - Thermostat Address: n001_t198772770918 Pnode: n001_t198772770918 128/true/'unknown' 01-05-19 15:07:13 Sev: 4 Problem with processing node: Presence Controller Address: n002_controller Pnode: n002_controller 128/true/'unknown' 01-05-19 15:07:13 Sev: 4 Problem with processing node: GS9 Address: n002_a407b6bccac1 Pnode: n002_controller 0/true/'unknown' 01-05-19 15:07:13 Sev: 4 Problem with processing node: AVRemote Address: n003_controller Pnode: n003_controller 128/true/'unknown' 01-05-19 15:07:21 Sev: 4 ISY Extra info in event: ST/Status/1/n001_controller/NoneOrderedDict([('fmtName', 'NodeServer Online')]) 01-05-19 15:07:21 Sev: 4 ISY reported and immediately cleared error for node: n001_controller () (seq:-99/9) 01-05-19 15:07:23 Sev: 4 ISY Extra info in event: GV8/**GV8**/1/n001_t198772770918/NoneOrderedDict([('fmtName', 'Connected')]) 01-05-19 15:07:23 Sev: 4 ISY Extra info in event: GV7/**GV7**/0/n001_t198772770918/NoneOrderedDict([('fmtName', 'Follow Me')]) 01-05-19 15:07:23 Sev: 4 ISY Extra info in event: GV6/**GV6**/1/n001_t198772770918/NoneOrderedDict([('fmtName', 'Smart Home-Away')]) 01-05-19 15:07:23 Sev: 4 ISY Extra info in event: GV5/**GV5**/60/n001_t198772770918/NoneOrderedDict([('fmtName', 'Dehumidification Setpoint')]) 01-05-19 15:07:27 Sev: 4 ISY Extra info in event: GV0/**GV0**/0/n003_d_3/NoneOrderedDict([('fmtName', 'Status')]) 01-05-19 15:07:27 Sev: 4 ISY Extra info in event: ST/Status/1/n003_d_3/NoneOrderedDict([('fmtName', 'Chromecast Online')]) 01-05-19 15:07:27 Sev: 4 ISY reported and immediately cleared error for node: n003_d_3 () (seq:-99/136) 01-05-19 15:07:27 Sev: 4 ISY Extra info in event: GV2/**GV2**/0/n003_d_4/NoneOrderedDict([('fmtName', 'Current App')]) 01-05-19 15:07:27 Sev: 4 ISY Extra info in event: SVOL/**SVOL**/41/n003_d_4/NoneOrderedDict([('fmtName', 'Volume')]) This is a small sample of the errors, they repeat as these nodes get updated quite frequently. Probably won't mean much if you aren't using Polyglot, but I'm using the Ecobee, AVRemote (for Chromecast devices), and Presence-Poly node servers. Have you started playing with ISY firmware 5 at all yet? Any interest in supporting it? Let me know if I can help provide more information.

On my TimeTemp screen, I use: LocationSize = 0, This eliminates it from displaying any location.

May it have something to do with another alert triggering while this Away alert is triggered? I just ran an errand and this is the typical soft console log of me coming home: 11-03-18 16:05:28 Sev: 1 Status change for Bay1-Sensor(24 2E A3 1) to 0 11-03-18 16:05:28 Sev: 2 Node alert fired: Garage Door1: NodeChange Alert (Armed) Trigger: Node 24 2E A3 1 status EQ 0 delayed 50 seconds IsTrue: True Invoke: Screen:GarageDoor1<screens.alertscreen.AlertsScreenDesc object at 0x73158690> 11-03-18 16:06:06 Sev: 1 Status change for Bay1-Sensor(24 2E A3 1) to 255 11-03-18 16:06:06 Sev: 2 Node alert fired: Garage Door1: NodeChange Alert (Delayed) Trigger: Node 24 2E A3 1 status EQ 0 delayed 50 seconds IsTrue: False Invoke: Screen:GarageDoor1<screens.alertscreen.AlertsScreenDesc object at 0x73158690> 11-03-18 16:06:27 Sev: 1 Status change for GarageHouseDoor-Sensor(2B 11 81 1) to 255 11-03-18 16:06:32 Sev: 1 Status change for GarageHouseDoor-Sensor(2B 11 81 1) to 0 11-03-18 16:09:07 Sev: 3 Alert screen AwayAlert cause cleared Here's one of the examples with the Anomolous alert: 11-01-18 19:39:24 Sev: 1 Status change for Bay1-Sensor(24 2E A3 1) to 0 11-01-18 19:39:24 Sev: 2 Node alert fired: Garage Door1: NodeChange Alert (Armed) Trigger: Node 24 2E A3 1 status EQ 0 delayed 50 seconds IsTrue: True Invoke: Screen:GarageDoor1<screens.alertscreen.AlertsScreenDesc object at 0x73158690> 11-01-18 19:40:14 Sev: 2 Alert event firedGarage Door1: NodeChange Alert (Delayed) Trigger: Node 24 2E A3 1 status EQ 0 delayed 50 seconds IsTrue: True Invoke: Screen:GarageDoor1<screens.alertscreen.AlertsScreenDesc object at 0x73158690> 11-01-18 19:40:14 Sev: 3 Alert screen AwayAlert deferring 11-01-18 19:41:17 Sev: 1 Status change for Bay1-Sensor(24 2E A3 1) to 255 11-01-18 19:41:17 Sev: 2 Node alert fired: Garage Door1: NodeChange Alert (Active) Trigger: Node 24 2E A3 1 status EQ 0 delayed 50 seconds IsTrue: False Invoke: Screen:GarageDoor1<screens.alertscreen.AlertsScreenDesc object at 0x73158690> 11-01-18 19:41:17 Sev: 3 Alert screen GarageDoor1 cause cleared 11-01-18 19:41:23 Sev: 2 Actual weather fetch for 19426(0) WU count: 95 11-01-18 19:41:50 Sev: 1 Status change for GarageHouseDoor-Sensor(2B 11 81 1) to 255 11-01-18 19:41:55 Sev: 1 Status change for GarageHouseDoor-Sensor(2B 11 81 1) to 0 11-01-18 19:42:14 Sev: 2 Alert event firedAway Alert: VarChange Alert (Armed) Trigger: Variable ISY:State:Cell_Home EQ 0 delayed 0 seconds IsTrue: False Invoke: Screen:AwayAlert<screens.alertscreen.AlertsScreenDesc object at 0x73158ed0> 11-01-18 19:42:14 Sev: 4 Anomolous VarChangeTrigger firing as task: Away Alert: VarChange Alert (Fired) Trigger: Variable ISY:State:Cell_Home EQ 0 delayed 0 seconds IsTrue: False Invoke: Screen:AwayAlert<screens.alertscreen.AlertsScreenDesc object at 0x73158ed0> One difference that caught my attention was the three times I've noticed this alert, the log entry "Alert screen AwayAlert deferring" always appears. While I see that at other times in the log, I don't see it very often. But, it's always present with the "Anomolous" message. Also, all three times the Anomolous message appeared, there happened to be a weather fetch in the mix.

Kevin - Your explanation initially seemed very likely. However I reviewed some of my logs, I'm not sure that's what's happening. Although, since ISY doesn't seem to log variable changes it's a bit hard to confirm. The condition has only happened 3 times since I installed the current version, so it's not happening very frequently and not at all a big deal. Just a curiosity. I use Tasker on my cell phone to update a variable on ISY based on location (via a php script on my home server). So, I was thinking it is entirely possible that it rapidly toggles a few times as I don't have any sort of delay or wait (or error checking) built into the process. However, I looked at my web server logs (since that's how my cell phone actually pushes the variable update) and it appears the phone app/Tasker is only making one call to change the variable when I've seen the log in the soft console logs. If there are multiple rapid variable changes happening, I'm not sure how. Not sure if it's helpful, but I should have also included the only other pertinent log entry on the soft console, which always happens at the same time as the Anomolous log entry. I have my logging set to "1", so I also see: Sev: 2 Alert event firedAway Alert: VarChange Alert (Armed) Trigger: Variable ISY:State:Cell_Home EQ 0 delayed 0 seconds IsTrue: False Invoke: Screen:AwayAlert<screens.alertscreen.AlertsScreenDesc object at 0x73158ed0> Like I said, not a big deal at all. Just a curiosity.

Kevin - I've gotten a couple of these errors in the logs. I haven't had much time to look into them, but any idea what they might mean? Sev: 4 Anomolous VarChangeTrigger firing as task: Away Alert: VarChange Alert (Fired) Trigger: Variable ISY:State:Cell_Home EQ 0 delayed 0 seconds IsTrue: False Invoke: Screen:AwayAlert<screens.alertscreen.AlertsScreenDesc object at 0x73158ed0> I never noticed this alert prior to the latest update. Any insights?

Thanks for the fix! I pulled it down a few hours ago and haven't had any errors since.

So, I've been playing around with the new weather provider, APIXU. Being fairly far out in the suburbs of Philadelphia, they don't seem to have many close stations. The temperature reported by APIXU for my zip code is usually ~2° cooler than what WU and my own outdoor thermometers display. I suspect this is because the actual location they are reporting for is a several miles north/west of my actual location. For all of WU's flaws, there were several folks in my neighborhood with PWS's, so it always seemed to have a good idea of what the local weather was doing. I did see on the Weather Underground API retirement announcement that they are indicating: I'll probably just learn to deal with the new weather service (2° is really not that significant for me). Perhaps if I get motivated I'll look at some other services...but that's not likely.

Certainly seems like your program gets triggered everytime the temp changes, even if it's below 80F. Personally I think I would have two programs set (two different) variables depending on the temperature. One program/variable for temps =>94F and one for <=80F. And, also have two different programs to control the outlet based on the state variables. I'm not an expert at this, but something like (probably need to add something to check after reboots): If temperature <= 80F Then stateVar_lowTemp = 1 Else stateVar_lowTemp = 0 If temperature => 94F Then stateVar_HighTemp = 1 Else stateVar_HighTemp = 0 If stateVar_lowTemp = 1 Then Set 'Outlet-AC' Fast Off Send Notification Else If stateVar_HighTemp = 1 Then Set 'Outlet-AC' Fast On Send Notification Else

So, I had looked at my ISY logs previously and didn't see anything there. I had presumed it was everything in the stream, as they log quite a bit. However, I looked at my programs...and that led to an "ah-ha!" moment. I run a program that updates a variable ISY_Uptime_Counter_hours, as one might imagine, hourly. I display this on a keyscreen (along with a bunch of other variables). I only have one idle screen (TimeTemp), which does not show this variable. And, I'm fairly certain the majority of the times I was seeing the error message I was not interacting with the softconsole and it was on the idle/dim screen (TimeTemp). To confirm all this, I initially removed that section from my variable screen, and sure enough the next hour no error message. To further confirm, I made a variable (Count_tmp) and another program that would update the variable every minute. I added the Count_tmp variable to my variable screen, and sure enough: 10-08-18 14:20:19 Sev: 4 Unexpected ISY event to screen: TimeTemp00 10-08-18 14:21:20 Sev: 4 Unexpected ISY event to screen: TimeTemp00 10-08-18 14:22:20 Sev: 4 Unexpected ISY event to screen: TimeTemp00 10-08-18 14:23:20 Sev: 4 Unexpected ISY event to screen: TimeTemp00 10-08-18 14:24:20 Sev: 4 Unexpected ISY event to screen: TimeTemp00 Not sure if this is the same issue that is occuring for you , but figured I'd pass it along. This is probably more information than you need, but if you want to reproduce it... This is a snippet from my variable config: [[Uptime]] type = VARKEY Var = ISY:Int:ISY_Uptime_Counter_hours Appearance = 0:48 red 'ISY Uptime $ hours',49:168 yellow 'ISY Uptime $ hours',169:17520 green 'ISY Uptime $ hours' [[Count-tmp]] type = VARKEY Var = ISY:Int:Count_tmp Appearance = 0:48 red 'ISY Uptime $ mins',49:168 yellow 'ISY Uptime $ mins',169:17520 green 'ISY Uptime $ mins' And this is my program to update the Count_tmp variable: If - No Conditions - (To add one, press 'Schedule' or 'Condition') Then Wait 1 minute $Count_tmp = 0 $Count_tmp Init To 0 Run Program 'Count-tmp' (Else Path) Else Wait 1 minute $Count_tmp += 1 $Count_tmp Init To $Count_tmp Run Program 'Count-tmp' (Else Path) My uptime program is identical, except different variable and only runs once an hour. With no If condition it kicks off at startup and continuously runs (mostly in a wait state). Hope it helps! At least I know it's really not an issue for me. Thanks again!

Any idea what these errors might indicate? I don't see anything in the logs on the ISY that correspond. I took a quick look at the code, but couldn't really tell what might be causing it. 10-07-18 23:29:42 Sev: 4 Unexpected ISY event to screen: TimeTemp00 10-08-18 00:29:44 Sev: 4 Unexpected ISY event to screen: TimeTemp00 10-08-18 00:30:00 Sev: 4 Unexpected ISY event to screen: TimeTemp00 10-08-18 01:29:44 Sev: 4 Unexpected ISY event to screen: TimeTemp00 10-08-18 02:29:44 Sev: 4 Unexpected ISY event to screen: TimeTemp00 They appear to occur roughly every hour and roughly 30 minutes opposite of the hourly weather updates (not sure that's relevant, just what I noticed). Best I can tell everything is working. Just curious.

Well, that got things back to normal for me now! Thanks! I'm sure I've tripped over the trailing comma issue before. I thought I had even tried adding it in at some point, but I was initially having multiple issues getting switched over...so who knows. And, I'm not sure why, but now the Conditions looks centered between the Clock and Forecast. It had been just off center/low when I had the time on two lines. Maybe an optical illusion... Thanks!

Hi Kevin! I'm still using my softconsole. I really like it and use it all the time. I haven't had much time the past few months to play around and had fallen way behind on versions. But, things were working/stable for quite some time, so there wasn't much need. This weekend I took some time and rebuilt my main unit. The changes to the TimeTemp screens through me for a bit of a loop. It took an embarrassingly long time to read in the usage notes that the backwards compatible TimeTemp screen was now TimeTempX. My fault for having poor reading comprehension skills. But, maybe in the future for changes like that, leave the 'legacy" screen name alone and go with something like TimeTemp2 for the new format. Just a thought. I ended up switching to the current TimeTemp screen, but can't manage to get the formatting just like I want. I can't seem to get the time format all on one line. This code make crazy things happen: TimeFormat = "%-l:%M: %P %a %b %-d" This works (but isn't what I want): TimeFormat = "%-l:%M %P","%a %b %-d" Also, is there anyway to eliminate the Label entirely? If I comment it out, I get the default "TimeTemp" and if I make the "LocationSize = 0" there still appears to be some space used (but, it's hard to tell). I haven't played with the new weather provider yet, but that looks promising.

Kevin - Just wanted to let you know I've been using the stable and everything appears to be working as expected. I probably had tested most of it in beta, but figured I would let you know that the stable appears good. And, I now have the degree symbol (°) on my TimeTemp screen.

I'll admit, I'm a bit out of my league. Kevin (kck) developed this code, I'm sure he'll have more insight, and I'm sure the log will help him narrow things down. Are you using a basic/minimal configuration just to see if you can get it working? My best guess is that the code is choking on the format of the response from the ISY for a particular device while it's enumerating the list of devices, but that doesn't really help you fix it.

I believe it's only been tested on version prior to 5. What errors are you seeing? Some logs to look at: /home/pi/Console/Console.log # this is the main log, presuming the process gets started. /home/pi/earlyprep.log # I believe this is only used during installation /home/pi/prep.log # I believe this is only used during installation /home/pi/log.txt /var/log/syslog # this captures the logs as the service starts. journalctl -u softconsole.service # Run this on the command line, and it will show the same as what is in syslog, but only for the softconsole

I apologize, I absolutely meant VNC. I rarely use VNC and so I'm not that familiar. I personally don't see much need for it on a device like this (but I understand for developing the software it could be helpful). Are you using it to display the console or just a desktop? The little I understand of VNC, I believe for a seperate desktop you would probably need a new instance like you are doing. As far as the config scripts go, the biggest issue I had was I misread the prompt about installing VNC/ssh on regular port. I answered N to that and should have left it Y. I was distracted and doing multiple things at the time and I think when I read it I thought it was asking if I wanted VNC installed, which is why I answered No. I wasn't paying attention, which is really on me. But, somehow the ssh port got set to "-100" which meant sshd wouldn't start...it took me a while to figure that out. Although had it gotten started on an odd port it probably would have taken even longer to find. (I pass no judgement on those that decide to run ssh on different ports. Obscurity can be one layer of security. I think there are much more important layers, but to each their own.)

I installed the new version on one of my Raspberry's. Since I had been messing with so much, I did a fresh install. It took me a bit, but I got everything up and running and it all seems good now (your config scripts get me everytime). I confirmed the >4 day forecast stuff worked. Why do you install your own VPN service and not use the built in one? I have to work 12 hour shifts the next four days, so I won't have too much time to play with things, but everything appears to be working for now.

I would very much like to see running it as a service implemented into the standard release at some point. I'll be more than glad to help in anyway I can. Some of my thoughts as I look at how your code works...(just typing out loud! ) Regarding the consoleexit bash script, I have to admit, there's a few things in there that seem redundant or I don't understand (which is very likely). I could probably easily make the changes to the bash script to get things to "work" with the systemd service, but question how to best handle the beta stuff. Doesn't seem like it would be a good idea to run the beta as a service and while changing the systemd unit scripts to do it would be possible, it seems like a generally bad idea. I think once the initial install implements the service/unit file, it probably shouldn't be touched unless there is good reason. I think the simplest/quickest way for the service/beta to be handled, is when choosing to running the beta, disabling/stopping the system service and then running the beta scripts as you do now (not as a service). When switching back to "stable", stopping the beta console script, enabling/starting the service would get you back. With the current setup, I presume a reboot of the Pi gets you back to stable, correct? Problem here is disabling the service would prevent it from starting on reboot. If the service is just stopped, it should be okay, I would just be concerned with running the beta and accidentally starting the service. Do you do any checks currently to know which one is running? I can't imagine both in parallel would be good... Presuming the scripts don't currently have anyway to determine if the beta or stable is running, I was thinking it might be best to write a file (like 'run_as_beta'), have the console script as it starts detect if that file exists (and that the path of the current script isn't the beta one). And, if it does exist to stop the service and start the beta version (like you do now). Getting back to stable would be as easy as removing the file (programmatically or otherwise). On exit, if no errors leave the beta file, if errors existed remove the flag to get back to stable (to mimic current behavior, I think) and restart service. A regular reboot of Pi would get still get you back to beta (service would start stable, it would check for file, etc). I don't have much experience with these RPi's, but is their network stack that unstable that they need to be rebooted that frequently? Is logging the netstat and ping on errors/unknown reboots really necessary/helpful? Or, was it left in troubleshooting a specific issue? When I was doing some work to my WiFi lately, I thought the console script handled the lack of wireless gracefully...until it rebooted. Maybe prompt for a reboot if ISY is not reachable after XX amount of time, or chose to wait? (Rebooting in my work world is akin to pushing a thumbtack in with a sledgehammer...it can work, but generally NOT acceptable.) If the network is that problematic, I wonder if toggling the network adapter wouldn't make more sense than a reboot (but even that seems strong handed to me). If necessary, a much nicer way to ping your default gateway in bash (because not everyone has the same IP address range!): DEFAULT_ROUTE=$(ip route show default | awk '/default/ {print $3}') ping -c 1 $DEFAULT_ROUTE We could probably also work out pinging the ISY address, which I think makes more sense than pinging the default gateway for most of the script issues. Now that you accept URLs or IP's for the ISY address that would need to be handled, but do-able. FYI - The bit of playing around I've done with the systemd service, it seems to work just as advertised. I have made some minor changes, which I'll get updated in my original post on the topic. Biggest change was the Restart=always -> Restart=on-failure (allows the program to exit cleanly without the system restarting it). The system attempts to restart the script anytime it is killed or not running (unless exited cleanly). If I borked something in the python code and it throws a code, it just keeps trying the restart until I correct the code. Then it starts right up.