Soft Keypadlinc-like Console from Raspberry Pi

[Screw Loose Dan]

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?

[kck]

I probably should have noticed these (there's a another one just like it) were still Warning level and made them detail log items.  They should be benign.  Interesting that you see them though.  Basically what has happened is that the alert triggered (looks like it is the state variable "cell_home" going to 0) but by the time the code to handle the alert is dispatched the condition is no longer true.  I think that could happen if the variable changed to 0 and very quickly changed back.  Just guessing here but are you using the connected state of a mobile on your router to change an ISY variable?  If so I suppose it is just possible that the phone could appear to disappear VERY briefly and cause this.  I didn't think this race could actually happen (and in my older code I don't think it could have) but since I went to using the store mechanism to handle ISY variables is might be just possible for the thread that handles the ISY stream to see the var change to the alert state, queue up the event to be handled by the main dispatch code, then see the state flip back before the queued event actually gets to dispatch.  In any case, since the actual handling of the event notices that the condition isn't true is just ignores it and you don't get the Alert screen.  I'll downgrade those log entries to where they should be - just surprised that the race can happen apparently with some frequency.  It will probably be a couple of weeks before I push a new update since I'm about to be out of town and I have some "in flight" changes in my home version that I'm not sure are stable yet (most aimed at ridding the log of pointless warning like these so that when you do see the error indicator in the corner of the screen it is something worth glancing at).

 

Kevin

[Screw Loose Dan]

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.

[kck]

More curious than you know!  I looked harder at the code that emits that message and I'm really scratching my head.  That code should only ever see an alert that as part of its condition includes a delay.  Basically the flow is that the variable change is reported which should trigger the alert evaluation.  If the delay is 0 then that evaluation just invokes the alert's action (in your case it should put up the Away Alert screen it would appear).  If, however, the delay is non-zero then the alert evaluation queues a task for "delay" time in the future which makes the alert reappear for execution.  The message you are seeing originates in this delayed execution code when it re-evaluates the condition and sees it isn't true any longer (other code should have noticed such changes and deleted the delayed task before it came ready).  But your condition appears to have delay of 0 and so should never even get queued for that delay handling code to see.  So while I still think it is benign I am really  stumped as to what is causing it.  I'll keep noodling on it.  Also, the next version of the console should have some (hidden) facility to look back at the event streams in cases of such oddities which may provide some insight.  If, after you get that code we are still seeing this, I'll ask you to send along the history buffer for the event stream for when it happens.  While there is quite a bit of tricky parallelism in handling the realtime environment of hub message, internal console events (like clock ticks), touch events, etc. it is still annoying to discover one of these odd bugs - especially when it would seem impossible.

 

Kevin

[Screw Loose Dan]

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.

 

[kck]

Nicely done - I am pretty sure you nailed it.  I had almost asked you before if you had another alert screen active.  I'll have to look at how to avoid the message for that sequence but I think what happens is that the Away screen is up, then the Garage Door alert screen is enabled.  If multiple alert screens are active they take turns deferring to each other.  The Away screen defers which queues it for later reactivation, then the cause for the Alert screen clears, then the queued reactivation happens, and I see the alert with the condition not true and I issue the warning.  That should be possible to suppress since it is a perfectly normal sequence of events - just requires the right setup and then the right timing of things.  Thanks!  I hate mysterious program behavior.

[kck]

I just pushed an update for anyone who is using this.  Changes in this update are mainly multi-console use improvement via optionally coordinating behavior via MQTT, lots of error message/handling cleanups/improvements, and some (hidden) diagnostic stuff.  One loss of capability was dropping WeatherUnderground support since they are killing their fre API at month end (but it supports since the previous release APIXU weather instead).  Most of the change was motivated by my needs having 8 consoles deployed across 2 homes where managing them when an error occurred had become a bit annoying.  Copied below is the full release note from GitHub.  The documentation in the usage notes file have been updated to reflect the new capabilities.

V3.2 is a notable release that will mainly be of interest if running more than one console. Its major addition is the use of MQTT when configured to allow multiple consoles to report their operational status and to coordinate any Warning or Error level log entries. This permits the user to look at the log on any single console and see any serious log entries made by all the consoles in the house. It also coordinates the on-screen error indicator across consoles. It allows a simple look at the current status of all running consoles, as well as the hardware/software of the systems they are running on. Finally, it allows external issuing of commands to all or specific consoles via an MQTT publish. These additions were motivated by my personal experience running 8 consoles across 2 homes. This version also moves all major system and screen parameters to the store model which makes them accessible to as screen configuration and alert parameters as well as via the MQTT set mechanism. In addition to this (which is only enables if you configure MQTT so not an issue if you don't) there are a lot of improvements in error handling of various ISY and HomeAssistant error cases. In particular, the console will now initiate an ISY query when it sees an ISY node with a communications error (motivater by a particular issue I had with my garage door opener). It also notes error conditions that clear as well as prolonged ISY busy periods (expect one at the overnight daily whole house query). In general, error messages have been cleaned up to avoid pointless Warning level messages where possible. Finally, some additional diagnostic capabilities were added to allow dumping of the history of events that led up to a situation. This version also deprecates WeatherUnderground support completely since it will be killed off by them at end of month. All the above has been added to the documentation.

[EVictory]

Kevin,

I have been working on converting my consoles to v3.2 and have setup an APIXU weather account.  As you know, WU service is ending 12/31/2018 and I wanted to switch over.  I have three consoles and have been working on converting just one first.  I managed to figure a good bit of it out but have run into an error that has stumped me.  The last three entries in the Console.log are as follows:

12-29-18 22:17:54 Sev: 3 Default hub is: ISY
12-29-18 22:17:57 Sev: 5 Error accessing ScreenParams:store['store']KeyError('store',)
12-29-18 22:17:57 Sev: 3 Exiting with history trace (None)

Right after these entries, the console fails to start.  A minute or two later, it will try again with same results.  I have attached the Console.log file.

To upgrade, I went into maintenance mode (tapped screen five times), selected Select Version, then Download Release.  After this finished, I went back and selected Use Stable Release.  Then I restarted the console.  It failed to start.  I then started modifying my cfg files, copying the upgraded files to the RPi using WinSCP and watched the Console.log file to see the affect.  I managed to get my APIXU key setup in the auth.cfg file and created a weathersources.cfg file.

PS: The 'Problem with processing node:' lines have been there sense v3.0.  I think they are caused by my PolyGlot and NodeServer ISY devices.  With v3.0, the console still worked even with these errors.

 

Console.log

[kck]

Probably tripped over a bug but we need to localize it a bit.  Add the lines:

LogLevel = 0

Screen = True

to the top of your main config file.  This will make the log output a lot more verbose.  Mostly it should identify the screen being processed at the time you see that error.  All the parameters that describe a screen appearance etc. now get stored in a common place internally.  ScreenParams is the name of the part of that place that holds those parameters.  The program seems to be trying to access something called "store" and not finding it.  I'm guessing you don't have anything like than in your configuration hence a bug.  However if you do have something called "store" that would be a likely clue.  In any case, run with the above and get me the log file from that.  FYI there should be a line that looks like "Screen of type" just ahead of the failure.  That should at least point at the type of screen you were creating when things went south.

P.S. I would expect those other errors are in fact PolyGlot related since I don't run a v3 system so don't see those newer node reports.  By the way, the delay in restart is set in the systemd config file that starts/restarts the console and is just there to avoid fast restart/die cycles when there is a permanent error like this.

Kevin

[kck]

Actually, if this error only happens once you've added the new weather screens then the other thing you could do is to send me the screen config files and the weathersources file (don't include your key) and I can just try running them here and see if I can find it that way.  You could quickly check that by just seeing if the console will run if you don't include any of the weather screens.

[EVictory]

The detailed logs were a big help.  It showed the last three lines as below.

12-29-18 23:15:08 Sev: 0 Screen-> New TimeTempDesc tt-Sensors
12-29-18 23:15:09 Sev: 5 Error accessing ScreenParams:store['store']KeyError('store',)
12-29-18 23:15:09 Sev: 3 Exiting with history trace (None)

This led me to look at the tt-Sensors.cfg file.  This file defines a screen that displays the temperature and humidity from some local 1-wire sensors I have setup with NodeServer.  Technically, it is displaying ISY variables that are set with the values.  What was causing the errors is I had a Location = command that still had the WU location in it.

location = pws:KLAFOLSO4

Once I fixed this to use the new location, SoftConsole loaded.

[EVictory]

Is there a way to suppress the location information obtained from APIXU for a weather location? 

For example, I have longitude and latitude defined for my location of Folsom LA.  However, the APIXU is displaying this as MARTINVILLE on the weather screen.  I know of no town named Martinville near here.  Below is my w-fols.cfg file.

[w-FOLS]
    type = Weather
    label = Folsom Weather,
    location = Folsom-LA
    BackgroundColor = black
    CharColor = lightgreen
    DinTo = 5

The MARTINVILLE is showing up on the line below the label (Folsom Weather).

By the way, thank you for such a great program!  

-Emile

[Screw Loose Dan]

8 hours ago, EVictory said:

Is there a way to suppress the location information obtained from APIXU for a weather location? 

On my TimeTemp screen, I use:

LocationSize = 0,

This eliminates it from displaying any location.

[kck]

Oops.  Dan is right that will work for the TimeTemp screen but when I added it for him, I didn't also add it to the Weather screen. It was an easy fix so I put it in just now.  However, since I have been doing some other things that I think are stable (been running in some of my nodes for a week or so) I don't want to make it the current release quite yet.  So I just pushed the change as "currentbeta".  It also has a change to try to suppress those ISY node processing errors from V3 type nodes that I don't understand in the program.  So you should be safe in selecting download beta and use beta for your system.  Let me know if that handles your problem.  Also, if you would do me the favor of running with LogLevel set to 2 once, you should see the node processing errors show back up in the log but with some more info to help me understand what those nodes look like.  It you can (no rush) send me a version of the log with the detail messages.  Then you can just delete the loglevel or set it to 3 (the default) and get back to a simpler log.

 

Thanks,

Kevin

[EVictory]

Kevin,

My weather pages now respond to the LocationSize = 0 commands.  Thank you.

Per your request, I have attached some sample Console.log files representing log levels 0, 1, 2, & 3.

Thanks,

-Emile

Console-Level-2.log

Console-Level-3.log

Console-Level-0.log

Console-Level-1.log

[kck]

Thanks for the logs - I took a quick look at them and I should be able to suppress the warnings about extra info.  Those come from how ISY reports on the new node types that the console doesn't understand.  FYI - I think you meant SceneProxy which is why you have those errors about ScreenProxy.  If things are working ok anyway then that just means the console guess a reasonable choice to represent the scene "state" and you could just delete the SceneProxy items - or leave them with the corrected name.  Also DimTo should be DimTO.  I really should find a way to be more flexible on capitalization - I'll stick that on the todo list.    The comm errors generally reflect that the ISY node is actually showing a comm error in the ISY dashboard.  When I see that I try a query to see if I can clear it but it is really between the ISY and the Insteon device.  On the other hand those "saw and immediately cleared" messages are some sort of ISY weirdness that I also tripped over once I started reporting comm errors.  Under some conditions the ISY seems to get in a state with some devices where it always first reports ERR (which is generally the node state after a comm error) and then in the very next record in the stream reports a valid non-error state.  This was driving me nuts because my garage door opener was doing it at times.  The ISY dashboard would not be showing an error - it was just that the stream reported an error and immediately a clear of it.  So I actually special case that which is the message you see in your logs.  In my experience, the ISY would seem to do this after there had been a real comm error that then cleared.  It looked like the ISY remembered that there had been an error and kept doing this until it next booted and then it wouldn't do it again until/unless the device suffered an intermittent comm error again.  Probably Michel and the gang should take a look at this one at some (very low priority) point.  If you see these a lot perhaps I should just downgrade the level of their reporting since they seem benign, but they do concern me a little bit since I can't explain them.

In any case, by the time I make this a general release (probably next week) I'll fix what I can.

Kevin

 

[EVictory]

I have corrected the miss-spelled SceneProxy and the DimTO statements.  Thanks for the heads up.  

I moved into this relatively new home last year.  I am experiencing a lot of communication errors between my ISY and various devices.  The home has many arc-fault breakers as well as many ground-fault outlets.  These are causing a lot of the comm problems. 

Ground-Fault Outlets - The electrician who wired my house took a lot of shortcuts.  Many of the SwitcheLinc devices are wired 'downstream' of ground-fault outlets.  I have been slowly working on either replacing the ground-fault outlets or rewiring them so that the SwitchLincs are not downstream.  The latter means adding additional ground-fault outlets on downstream outlets to meet code.

Arc-Fault Breakers - I have some SwitchLincs that give comm errors when installed on a particular circuit protected by an arc-fault breaker.  Yet if I move the SwitchLincs to another circuit, they work fine with no comm errors.  The loads are simple lights.  It appears that the arc-fault breakers are causing comm errors, especially on circuits that are furthest from the breaker panel.

About half of my devices are dual-band.  I have tried to ensure I have a dual-band device in every multi-gang box.

Anyone had any experience with arc-fault breakers causing comm problems?  

-Emile

[Screw Loose Dan]

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.

 

[Screw Loose Dan]

On 12/13/2018 at 4:38 PM, kck said:

V3.2 is a notable release...

In particular, the console will now initiate an ISY query when it sees an ISY node with a communications error (motivater by a particular issue I had with my garage door opener)...

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.

[kck]

Re the V5 firmware - I haven't run that yet.  There are a couple of special cases already in the code for issues others reported with differences in how the ISY reports certain things.  The errors that you are seeing are the same ones EVictory is seeing and are due to my not expecting to see those nodes.  For now I have (I think) added recognition of those sorts of nodes and don't error log them on normal log level 3 (though I will report them if you set a more detailed level.  This change is in the current beta version so you might try that and see if it works ok (I'm having to fix this sort of thing in the blind).  I hope to push that as the current release Monday if I don't see any issues but then I'll be traveling for 3 weeks so don't want to push anything problematic.

On the query thing, I don't do anything special for battery devices but generally they shouldn't be reporting comm errors.  The comm errors seem to arise from real Insteon issues with getting good messages through.  I had been seeing a lot of issues with this from my Garage Door Opener because its controller is not dual mode.  (I finally just plugged a range extender right into the extra socket on the opener controller and that is dual mode and seems to have fixed my issues.).  Basically what I do if I see a comm error get reported is to trigger a query after a small wait time (in case other things clear the problem).  The query is the same thing that runs daily at 3am in a standard ISY setup.  So if the error is intermittent this can fix things without waiting until the next daily house query.  If not - oh well!  Since multiple consoles will see the comm error I also randomize a bit across the consoles so that they don't all launch queries in lockstep.

 

Kevin

[Screw Loose Dan]

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!

[chrisb5]

Got a couple RPIs for Christmas so I'm trying to build a new version of the console on a RPI 3B with the Raspberry 7" LCD touchscreen.

I started with the raspbian stretch lite image on an 8Gb microSD. 

On the initial run of /boot/pisetup.sh I got the following errors:

2019-01-06 00:00:18 (10.9 MB/s) - ‘lxterminal.conf’ saved [1365/1365]



Traceback (most recent call last):

  File "getsetupinfo.py", line 2, in <module>

    from future.builtins.misc import input

ImportError: No module named 'future'

Proceed?

 

 

I went on and after the reboot ran the /home/pi/installconsole.sh script. This bombed badly; apparently the "pip" package was not present (not on that distro?). Also I see an error about cannot remove tmp:

*** Setupconsole ***
Created: Console
Created: consolestable
Created: consolebeta
Created: consolerem
--2019-01-06 00:12:27--  https://github.com/kevinkahn/softconsole/archive/currentrelease.tar.gz
Resolving github.com (github.com)... 192.30.253.113, 192.30.253.112
Connecting to github.com (github.com)|192.30.253.113|:443... connected.
HTTP request sent, awaiting response... 302 Found
Location: https://codeload.github.com/kevinkahn/softconsole/tar.gz/currentrelease [following]
--2019-01-06 00:12:27--  https://codeload.github.com/kevinkahn/softconsole/tar.gz/currentrelease
Resolving codeload.github.com (codeload.github.com)... 192.30.253.121, 192.30.253.120
Connecting to codeload.github.com (codeload.github.com)|192.30.253.121|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [application/x-gzip]
Saving to: ‘currentrelease.tar.gz’

     0K .......... .......... .......... .......... .......... 1.17M
    50K .......... .......... .......... .......... .......... 2.06M
   100K .......... .......... .......... .......... .......... 1.92M
   150K .......... .......... .......... .......... .......... 2.29M
   200K .......... .......... .......... .......... .......... 2.39M
   250K .......... .......... .......... .......... .......... 2.39M
   300K ....                                                   2.14M=0.2s

2019-01-06 00:12:27 (1.92 MB/s) - ‘currentrelease.tar.gz’ saved [311361]

Stage standard stable release
./scripts/upgradeprep.sh: line 3: pip: command not found
./scripts/upgradeprep.sh: line 4: pip: command not found
./scripts/upgradeprep.sh: line 5: pip: command not found
./scripts/upgradeprep.sh: line 6: pip: command not found
./scripts/upgradeprep.sh: line 7: pip: command not found
./scripts/upgradeprep.sh: line 8: pip: command not found
./scripts/upgradeprep.sh: line 9: pip: command not found
./scripts/upgradeprep.sh: line 10: pip: command not found
Initial install
Setup systemd
Dir: /home/pi/consolestable
Installed staged stable

----------------------------------------------------------
----------------------------------------------------------
Set Console to Start at Boot
Sun  6 Jan 00:12:29 EST 2019
----------------------------------------------------------
----------------------------------------------------------
Failed to enable unit: File softconsole.service: No such file or directory
rm: cannot remove 'tmp': No such file or directory

----------------------------------------------------------
----------------------------------------------------------
Install and setup finished
Sun  6 Jan 00:12:29 EST 2019
----------------------------------------------------------
----------------------------------------------------------

----------------------------------------------------------
----------------------------------------------------------
Rebooting in 5 seconds
Sun  6 Jan 00:12:29 EST 2019
----------------------------------------------------------
----------------------------------------------------------
Rebooting 5
Rebooting 4
Rebooting 3
Rebooting 2
Rebooting 1
Reboot . . .

I manually installed that per instructions on the wikipedia page (curl https://bootstrap.pypa.io/get-pip.py | python) and tried the installconsole.sh script again.

It made it through the script to the end after that but the console doesn't start; and when I try manually I get:

$ python -u console.py
Traceback (most recent call last):
  File "console.py", line 26, in <module>
    import pygame
ImportError: No module named 'pygame'

Running out of steam at this point. What to do?

-Chris B

 

[kck]

@Screw Loose Dan

Those were the result of one more place where I didn't know how V5 reports things.  Think I've fixed it and put in the new beta.  If you can check it that would be great since I can't verify the fix.

[kck]

@chrisb5

I think the root of the problem may be starting with the lite Stretch version.  Not sure what the drop from that but from the errors it looks like perhaps a bunch of Python.  I suggest to rebuild a system with normal stretch with desktop (don't think you need the one with the extras beyond that).  Looks like the current one at https://www.raspberrypi.org/downloads/raspbian/ is from 11/13.  On the fresh system at a terminal prompt types "sudo pip install --upgrade pip" and you should get the latest version of pip which is something like 18.0.  (This isn't strictly necessary since an older version is generally fine but it should give some assurance that the system is all there.)  Just to make sure things are solid type "sudo pip3 install future".  The pisetup script actually does this  (at line 69) but it is about the only thing that could go wrong before the run of the run of getsetupinfo.py.  From there the install scripts should work fine - I use them fairly regularly in building test systems though I haven't built one in a couple of months.

 

 

ETA: Looking at some documentation it appears that Python3 is not included in the lite version which is required to run the console.

[Screw Loose Dan]

35 minutes ago, kck said:

@Screw Loose Dan

Those were the result of one more place where I didn't know how V5 reports things.  Think I've fixed it and put in the new beta.  If you can check it that would be great since I can't verify the fix.

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!