kck

Just pushed V3.11 as a major release that supports Polisy nodes better. Other stuff as well - see release summary below: Fairly major release. For ISY systems it now handles differences in connections to 994 vs Polisy hubs and selects the proper parameters for each. It adds support for Zwave nodes on ISY systems (previously only Insteon nodes were supported). It also now supports other node types connected via nodeservers that do on/off operations via a config file parameter (NodeServerSwitches) that defines which such device types should be handled. For Home Assistant hubs, the console now handles fan, cover, input_select, input_number, and input_bool domains. The input domains can be accessed by a new setinput key type. Also added for HA is a speccmd key type that will allow any defined service call for an HA node, which allows handling of HA domains that are not natively supported in the console or special commands specific to the domain. Finally, for all keys the control over key appearance has been greatly enhanced. Previously, VAR keys had access to Appearance parameters that would control their appearance based on the value of a variable. This has been extended to all keys and, in fact, the old default behavior for On/Off is now actually just a default set of appearance parameters for a key based on the associated node state. This is all updated in the useage notes. Final note: since I no longer have a working ISY994 system available to me my testing ability for ISY compatibility is limited. However, as this release indicates there is sufficient debug hooks in the code that I should be able to work with any user who runs into issues with a ISY994 or Polisy hub.

@Javi Your last exchange with tazman provided the pointer to fix my version of this issue. I was specifying subprotocol ISYSUB because at some point in the past this was required. My guess it that you guys moved to a different websocket library at your end that doesn't need or handle that subprotocol specification and that this resulted in the failure. I deleted specifying the subprotocol and things are now working as they should. At least this thread should provide informal documentation should anyone else trip over this, but you might want to stick a note someplace in the documentation that this may have changed. Thanks for the help. Kevin

@javi Appreciate you looking when you can. Don't think it is the library suppressing the port because essentially the same code flow exists in my console for the case of a Home Assistant hub which also uses websocket streams for updates. It runs its subscription on port 8123 which is what my code passes in to that type of hub and that works fine. So it seems that an actual port number embedded in the url stream works fine to direct where the subscription happens. My guess is that some other header requirement subtly changed which is what is rendering my call (and the one in the HousePanel) invalid. I'm going to keep trying to isolate it if bambamf16 can get me some debug streams. I, unfortunately, don't have a Polisy I can test against. Thanks.

That's basically the same behavior that I see. Any app of this sort (mine or apparently HP) wants to monitor the stream for device state changes because that way it sees the changes no matter their source. On the other hand, to make a state change it uses a direct rest call. So you get what we are seeing - actions work but the result isn't registered back at the app because it can't see the stream of events. It sounds like in the case of HP the author gets the initial state of the devices by a direct query which is why a refresh of the app gets the correct data. In my case, I don't do this because I know that the websocket stream will give me all that state info, so I just use the stream for the initial case as well as the updates.

I am the author of this app. It uses a common Python library (websocket-client) to subscribe to the stream. It is trying to open ws://10.0.1.71:8080/rest/subscribe so as I understand it that would be the correct port for Polisy. This has always worked on the 994 but here it appears that there is something awry with the headers. Authentication seems to be correct because a direct call to get the nodes from the Polisy gets good data - it is just subscribing to the websocket stream that seems to have broken. As I said, I'm fine having to adjust my code but at the moment I don't know what changed between previous version and this current stuff. ETA: it is all open source and can be found at https://github.com/kevinkahn/softconsole/tree/master/hubs/isy in the isyeventmonitor.py module around line 475.

@Javi While the fix may mean a change to the app (in my case the console) the issue is clearly caused by some change in how Polisy works versus how previous versions work. So I need to find out what has changed about subscribing to the websocket stream in the newer versions. Any help would be really appreciated since clearly the OP's app and my app work fine with the older versions.

Just pushed V3.10.1 as a minor release to fix a few bugs. Release summary: Minor release to allow correct handling of HA hubs that use customized port instead of 8123. Also adds rate limiting of control traffic for HA dimming similar to that for ISY dimming. Adds support for multiple parameters for HA runprog key calls. Also includes various minor bug fixes and internal performance improvements.

Yup. I just verified that this is a bug (or at least a feature deficiency :-)) in my code and I'm in the middle of fixing it. For the next release I will honor a port number specified in the address field for the hub so you could just put maison.gaetanlord.ca:80 in your config file and have it work. Sorry about that - as you might expect every new user brings new learnings to the humble programmer. I'll try to push out a new release in the next couple of days so you won't have to run modified code. Kevin

Those History Buffer files only get created for certain errors that are logged in the main Console.log and are to provide the sometimes helpful information about what was happening just before the error. So if you look in the Console.log you will see a lot of Connection Refused errors appearing. For some reason the winsock stream from HA is not being accepted or is failing after it is accepted. In the main Console.log file what sorts of errors do you see? Actually, best would be to attach that Console.log file so I can see where things get to before they fail. I'd expect to see an access accepted message, a report of the HA entities that were processed, and a message that it had competed creating the structure for the hub. Then later a message about a WS stream opened. The fact that you are getting a connection refused after the token was accepted is strange. Just to verify, does your HA instance operate on the standard port 8123? It looks like I currently hard code that port which I shouldn't do. If you have relocated it off 8123 that might cause this if you then coded your port into the address. If that is what is going on, this is a bug at my end that I need to fix. Let me know.

That message literally means that the console issued a request to the address of your HA instance to validate the access token and has heard nothing back. In the log file it says you set the address as maison.gaetanlord.ca but in you post here you have is as maison.example.com. I'll assume that you posted an old/edited version of the config file. In any case, it seems a bit unusual to be trying to access the HA instance via a globally formed DNS name (that .ca at the end). Are you sure that works in your context given how you have set up your local network and DNS service? If you are running a NAT at your house then you would have had to open a port forward for port 8123 to your HA instance. That's kind of dangerous. My guess is that you should be using a local address of some sort, e.g., maison.local or the like that will resolve to an IP address in the local range of your house (likely 192.168.1.xxx). For example, at my house I run with a local domain name of pdxhome and so reference my HA instance at servername.pdxhome. In any case, a fully safe way to get started is to set the address to the actual IP address of that HA server system. In fact, it's fine to just leave it that way so long as you can insure that it will always get the same address when it boots, probably via a static assignment in you DHCP service. As to the dark screen: You should be seeing the log go by as white letters against a blue background as the console starts up on your 7" display. Unfortunately, there is some inconsistency in the Linux systems as to what the name of the frame buffer is. Look at the directory /dev on your console system and see if there is an fb1 as well as an fb0 there. If so, create a file called screendefinitions in your Console directory with the 2 lines: pi7|/dev/fb1|fbcon|Pi7 pi7B|/dev/fb1|fbcon|Pi7 That should cause the console to use fb1 as its frame buffer and then you should see the boot log scroll by as the console starts up. If I over-assumed your understanding in this answer, ask again and I'll try to help some more.

Glad you got this working. I'll beef up the comments in the usage notes a bit in the hope it will make it easier for any future user.

Greg, I looked more closely at the code just now and the only way I can see that you would get that message in that form is if you apikey is being read as an empty string. In that message, you will note the ?key=& part. The actual apikey should be appearing after the '"'. If you had left the apikey parameter out entirely, you'd see a "N/A" there. But it looks like the key is actually empty. If the key were present but just wrong you'd see the same message but the bad key would appear there. So I would look closely at your definition of the weather provider in the config file, specifically at the line that is apikey=string and see if there is something odd about it. If you don't see anything, send along that file (alter the key itself if you want to be secure) and I can try to cause the error here.

I can look at this in more detail tomorrow but I think it is your auth info. It should only have 2 lines after the [Weatherbit]. One is type=WeatherProvider and the second is apikey='abcde235666' of course replacing the stuff in the quotes with your key. No need for a username or password. That's all encoded by them in the key. That url doesn't seem to include the key which I suspect is why they are calling it forbidden. Kevin Sent from my SM-G960U1 using Tapatalk

Greg, That would seem to indicate that the target screen was not successfully created. That would happen if there were any errors in the target screen. Couple of questions: what screen does the error message actually reference? I.e., you have xxxxxx in your description but in reality that named an actual screen. Look at the log and verify that there were no error messages associated with anything in that screen. For example, in the snippet above you had [[Kitchen Lights] which I assume was just an editing error but there would need to have been a ']]' at the end of that line rather than a ']'. The config file parser library that I use is rather picky. I would expect that you will find a message of the sort "Keypad screen xxxxx not created due to error (<some exception info>)" in the log for the screen that is reported as not found. Alternately, double check the spelling for the screen name (the string in [[ ]]) and the string in the ScreenName = line. If there is a typo in one of those and they don't match you'd also see this. If neither of these lead to a fix then send me the actual log file (Console.log) and the config files and I'll track it down for you. Kevin

V3.10 Dimming Support I just pushed a new release of the console that has a significant new function in that it supports adjusting dim level for dimmers for both ISY and HA hubs. Release blurb below and usage notes updated. Significant release to add capability of using long presses and gestures on the touchscreen. HA light domain nodes (dimmers) and ISY nodes of type 1 (dimmers) now have the added feature that holding a long press on their screen buttons will bring up a brightness slider. Moving your finger along the axis of the slider will adjust brightness for the light. Note that due to differences in how Insteon/ISY and HA/Zwave handle dimming the physical responsiveness of HA nodes may look quicker at the light itself. This is due to rate limiting of the Insteon network traffic. Tapping OK will return to the parent screen with the new brightness while tapping Cancel will return but return the brightness to what it was. This feature also works for ISY Scenes via the console's scene proxy support so that the common idiom for implementing 3-way lights via a set of switches in a scene is supported as one would expect. Note that on capacitive touch screens this works very well and very responsively. Resistive touch screens generate a huge amount of "noise" in the form of non-existent touch/release events while holding down and other similar random things. The code has a lot of "dejittering" for all of this with the result that the resistive screens may seem a bit more sluggish in their response to finger movement, but in my experience still quite acceptable. The slider displays by default in the "long" direction of the screen but can be overridden, see the usage notes. In addition to these changes, there is now an alternate way to bring up the maintenance screen via a single diagonal gesture from the upper left to the lower right of the screen. (Note: if the screen is dim you do first need to awaken it with any touch.) Note that this has required a significant revamp to the touchscreen handling code so if you do see any apparent weirdness please report it. Also, given that the console can now see length of touch and movement, any suggestions for other uses of that capability are welcome. Finally, in the event that you do see strange problems with touch, you can for now revert to the previous touch driver system by creating an empty file in /home/pi names .forceoldtouch.

@Whitehambone I just pushed V3.9.3 to github which is a minor release that should fix the issue with Adafruit having changed their screen install scripts. I've tested it with a 3.5 Resistive PiTFT and it worked fine. It also should avoid any crash that occurred even if you were using some non-Adafruit PiTFT. Let me know of any issues.

No - nothing you did wrong. It appears that the guys at Adafruit again altered their scripts without much notice and the shell script that I was calling has disappeared. It looks like they now have a python script instead. I will have to dig into that to see how to call it and make sure it leaves things as I need them. Probably realistically can't get to this until Monday since I'm out much of Sunday. I'll get on it and see how to fix it for their new stuff. Sorry about this - not my fault but still annoying to see it happen and I'll try to fix ASAP. Kevin

I haven't played with it so don't really know anything too helpful. However, the way the weather stuff works in the console is that the purpose of the weather provider stuff it really only to load stores with the current reported values so that they can be separately displayed by one of the screens. A quick look at Weewx seemed to show that it can report information via MQTT. If that is the case, then you should be able to define some entries like those in the example mqtt.cfg file that would pick off the values it was reporting and put them in the MQTT store. Then you could display them as any other item in a store, in this case as something like MQTT:temperature. That should allow you to show any Weewx information on the console. I don't see any particular difficulty in doing this, but as always there might be some gotcha someplace that I'm not thinking of, so if you try it and run into issues let me know.

I have just pushed a minor bug fix release 3.9.2 that addresses some of the issue above as well as some other things I happened upon. Please note the note at the bottom of the blurb (think I probably blew out my getting old PLM on a power outage - arg.) Mostly fixed minor bugs. The console had expected incorrectly that there would always be folders defined in the ISY and that there would always be variables and scenes defined. This is fixed in this release to allow these to be empty. Also, rather than shutting down and restarting if the console can't initialize a hub, it now replaces the hub with a dummy hub that allows the console to start. This caters to a situation I had where one of my hubs became (semi) permanently unavailable and as a result consoles that have references to that hub wouldn't start to allow access to other working hubs. To reconnect to the off line hub the console does need to be restarted when that hub again is up. Some minor functional additions: this release supports scenes on the Home Assistant hub. Note that HA scenes can only be turned on (unlike ISY scenes). A console button corresponding to a scene issues the corresponding HA scene.turn_on command to the hub. Previously, when displaying the log via the maintenance screen you needed to scroll page by page to either the top or end of the log in order to exit the display. Now a double tap on the top half of the log screen goes directly to the 1st page of the log and a double tap on the bottom half goes directly to the last page. From there a single tap exits. Finally, the "Clear Matching Error" option on the network command screen now behaves more usefully in that it issues the command to all consoles and the match itself need not be completely identical for the match to work. It need only be "close" thus handling messages that hit all consoles that differ only in the address listed for some Python item. Note: My own ISY system is currently down after a power outage and it will be a while before I can restart it since it is in a different location. Thus, the ISY changes in this release have had more limited testing than I would normally do. If you encounter any significant errors, you can revert to the previous version by moving the "previousversion" directory in consolestable back up to be consolestable. And of course report the issue to me so I can deal with it.

Great. I'm happy to help if you run into any other issues. I can't think of any reason that you should have to name the consoles differently that come from the ISY. However, your router might have some objections to multiple instances of a name for DHCP and the like. I name my consoles for the place they are located (as you can sort of see from the example configuration files). Since the console will default to trying to look for its configuration file based on the node name, that lets me load all the configurations on to each console blindly and it will pick the one to use based on its name. That is just a convenience since you can always just use config.txt as your config file. If you do happen upon any cases where you figure out you had done something wrong but that the console log wasn't very helpful in figuring it out, I'm always interested in those case since I may be able to offer better error messages. Once someone has the console up and running you don't tend to notice such things that could be improved so I'm really interested in new user experiences that can smooth out initial effort with the tool. Re the garage door thing. I do that at both of my houses. At the one with the ISY, I use the Insteon garage door product which reports door status as well as allowing control of it. I have alerts on most of my consoles in the house that start flashing at me if the door stays open for an extended period of time. The alert will also let me close the door, although since you're not in visual contact with the door when you do that, it is a little dangerous. At my seasonal place I use Zwave and Home Assistant as the hub and there I have a couple of cheap door sensors I got from Monoprice that report the status of the main and golf cart doors. I use those to trigger alerts and also, since I have some zwave switches with LED status lights on them, also to alert via those.

I want to make sure I understand what you are seeing. What you should see is that after starting the screen turns blue and you see the boot log being displayed on the screen as the console comes up (this is the same entries that you see recorded in the Console.log files up through the message about arming alerts). At the end of this initial log you would then see the screen change to the home screen you have defined. If you aren't seeing the blue logging screen then there is something amiss regarding your screen settings for the console. My best guess for that is that I notice that your console is using /dev/fb1 whereas my similar system (on a 7 inch screen) is using /dev/fb0. Ever since Buster there has been something odd in the OS where some systems have an fb1 and some don't. There is a kludge in the code to try to catch this but it may be that for your system fb0 is your touchscreen and fb1 is something else (perhaps an HDMI screen that was connected during system build). In any case, if you aren't seeing the log, edit the file .Screentype in the home directory to delete the "B" at the end and that will turn off the check for the Buster kludge and should get you back on fb0 (which you should also see listed as the screen near the front of the log). Separate from this, the console is seeing communications errors from your ISY. These are not comm errors between the console and the ISY, they are comm errors between the ISY and the Insteon device that get reported in the event stream to the console. The console attempts to prompt the ISY to recommunicate to such devices which is what the messages about the query attempts are. It looks like the ISY gets through to the node but that it is having some difficulty doing so. The message about ISY busy means that the ISY issued a busy status into the event stream that lasted nearly 22 seconds (looking at log.1). That is kind of long which is why the console logs it. Short busy periods are expected but longer ones not so often. I mostly see those in my house for the 3am "query all" that the ISY does and for a evening and morning time when I have ISY programs that turn down the leds in bedroom switches - that takes a surprisingly long time to do. The busy periods aren't a real problem other than that they create long lags for the console to actually turn a light on/off or the like. But if you are seeing a lot of them it does suggest you may have noise on your power lines or that the device in question is just weak or distant from its nearest relay point. Finally, it does look like you have an error in your config file of some sort. The message about the key binding missing shouldn't be there. This might be my fault if you are using the minimal example. I did make some changes a while back to the install scripts that could have left a bug there - thought I tested it by perhaps it slipped by. In any case, take a look at the config file and see if it looks right and if you can fix it post it to me and I'll take a look.

May be another case where I don't handle the null situation correctly and no user has had that situation to trigger the bug. So - do you have integer variables but not any state variables in your ISY? If that is the case, try defining a state variable (doesn't need any particular value or use - just needs to exist). I think I am expecting that there will be at least a single state variable and a single integer (non-state) variable and am not handling the case when either type has no members. If this fixes it, then I'll have to do a better job of noticing this case and allowing for it. Again sorry - every new user always seems to exercise the ISY and console in slightly different ways and discovering latent bugs tends to be the result. Kevin

Arg! My original analysis was correct - I just didn't quite think it far enough in terms of Python and what the ISY was likely sending across. This will sound really silly but create at least 2 folders and it should work. Don't even think you need anything in them. Longer version in case you are curious and do any programming. The ISY sends across a json structure that Python internalizes that has all the node/folder information. With no folders the ISY doesn't include any 'folder' field in the json. That was your original situation that I had simply not realized would be the case. The code expected that the internalization of the json would yield a dictionary entry for 'folder'. Now part 2. With multiple folders (the case the code expected) the value of the dict entry for folder is a list of folder items (which if you are a Python guy are dicts). When there is only 1 folder the value of the dict entry for folder isn't a list of one folder item but instead is just that folder item. The code wants to run through a list. Boom! That is why 2 folders should do the trick for now - it will cause a list to be created. Definitely a bug in my code - I'll get a fix in place next release (which is probably next week since I have other things that I've worked on since the last update).

OK - guess we'll have to look a little deeper at what your ISY is returning. Could you edit your config file (probably config.txt) and right at the front of that file add the single line: ISYDump = True Then run the console and you should find in your Console directory a file struct.dmp and send it to me. There will also be a file xml.dmp that I don't think I will need but to save time in case I do attach that one as well. Those should let me see exactly what the ISY is returning when queried as to it devices. I hope that points directly at the issue. I'll be out for a while starting a about half an hour so I may not get back to you until later tonight my time (Pacific Time) so depending upon where you are you may not see a response until tomorrow.

No what you are seeing isn't related to your config files. It is something about what the ISY is returning to the console. Are all your devices in the ISY at top level? I.e., do you have any folders defined to organize your devices in the ISY? I think perhaps that the ISY doesn't return the folders list to me if there are none and I've never noticed that because everyone who has used the console has had at least one folder defined. If that is what is happening I should probably handle that case correctly. So - quick fix. Try creating one folder in your ISY device list. I doubt you even have to move a device into it. See if that fixes things. If it does, I'd just leave it there empty even if you don't want to organize things into folders and I will handle that "no folders" case in my next update just so you or others don't need to kludge it like this. If, on the other hand, creating a empty folder doesn't fix it, try moving one device into the folder and see if that does. If even that doesn't fix then we'll need to diagnose more. Sorry for the problem. Kevin