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.