Soft Keypadlinc-like Console from Raspberry Pi

[kck]

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

[Greg]

Ok,  I will look more closely for an error related to the screens.  The errors that I have seen in the log have been related to some zwave devices that I am not currently using.  I thought I had disabled them all in the ISY but I am still seeing one of them showing up in the log.

The only screen on that I can think of is with a Lamp Link module that it is complaining about.

 

Thanks again for the reply...at least I know that my fundamental logic is correct and it is more likely a fat finger error. 

 

Greg

[Greg]

Found the problem....I had copied one file to create the template for the other config files, I just had not changed the name in those files...ie I created 8 files 1.cfg, 2.cfg 3.cfg but inside they all had [1].  

Still am having a problem with the lamp link module.  If I can't figure it out I will give you another shout out.

Greg

[Greg]

Hey Kevin,

Me again.  Made progress today.  Found or at least corrected the error I was getting on the Lamp Link module.

Now I am trying to get the Weather information flowing.  I signed up for the free account at Weatherbit.  Got a username, password and apikey.   Looking through the documentation I can't seem for figure out how it all works.  So far I have tried creating a .cfg file and putting all the information in there...no go.  Then I put the a section into the auth.cfg file with weatherbit, type=weatherproider, username=xxxxxx, password=xxxxxx, apikey=12345bfxxxx.

No matter what I seem to do in the log, I can see it setting the lat and log correctly, then it goes down and does all the ISY stuff.  When everything else is done in the initialization it tries to actually retrieve the data from weather bit and I get a:

403 forbidden error that lists the weatherbit url however it does not seem to list the apikey

03-19-21 22:17:55 Sev: 4 Weatherbit failed to get weather for Vancouver last Exc: 403 Client Error: Forbidden for url: https://api.weatherbit.io/v2.0/current/?key=&lat=45.586497654&lon=-122.591830966&units=I

03-19-21 22:17:55 Sev: 4 2 weather fetch failures for: Vancouver No weather for 1616217475.200668 seconds

 

Thanks for all your help!

Greg

[kck]

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

[kck]

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.

[Greg]

Finally got this bit working.  For those that follow me, here are the 3 pieces of code you will need to get this all going:

First edit your auth.cfg file to contain the bits needed for access to the data.  Watch you upper and lower case (caused me hours of trouble tracking.  The yyyyyyy below after the IP address is because I use a custom port for access to my ISY device.

[ISY]
type = ISY
address = 192.xxx.x.xxx:yyyyyy
user = uuuuuuuu
password = *********
[Weatherbit]
type = WeatherProvider
apikey = ****************************

Next you need a file to define you location and refresh time.  In the example below I used Kevin's location as it is close enough to mine.  I just renamed it from PDX to Vancouver.  I will probably refine to location now that I have the basic code working.  Not the SINGLE [] surrounding the Weatherbit above and the Vancouver below.

[Vancouver]
type = Weatherbit
refresh = 60
location = '45.586497654,-122.591830966'

Finally I again copied one of Kevin's files and just modified it slightly to match me information.  Again the single [].  The location parameter needs to match the single [] in the above file.

[TimeTemp]
type= TimeTemp
label = 'Vancouver',
location = Vancouver
TimeFormat = "%-l:%M:%S%P","%a %b %-d"
ConditionFields = Sky,Temp
ConditionFormat = "{d[0]} {d[1]:.0f}"
ForecastDays = 2
ForecastFields = Day,Sky,High,Low
ForecastFormat = "{d[0]} {d[1]}"
ClockSize = 50
LocationSize = 35
CondSize = 30, 20
FcstSize = 25,
CmdKeyCol = blue
BackgroundColor = midnightblue

 

Hope this helps someone in the future.  Thank you Kevin for all your help todate.

 

Greg

[kck]

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.

[gaetanlord]

Trying to learn your software and I have a hard time doing the basic. Wonder if you could just point me in the right direction.  

No intend to use my ISY, I want to connect only to HA. All my insteon devices are now managed under insteon2mqtt

I have a raspberry pi 3 model B with the official 7in touchscreen.

I try to reduce my test to a minimum and build from it, but no luck.

Once I start the following config.txt, I get a black screen

cfglib = cfglib
DefaultHub = MAISON
HomeScreenName = MyClock
PersistTO = 30
DimLevel = 5
DimTO = 15
DimIdleListNames = MyClock,
DimIdleListTimes = 20,
MainChain = MyClock
[MAISON]
type = HASS.1
address = maison.example.com
password = long_token
 

I would expect to have a clock displayed, and a connection message to HA. I know the HA token key is working I test it manually with the command curl, but I get recurring message about the connection not responding

What would be my stupid mistake

Console.log

[kck]

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.

[gaetanlord]

1 hour ago, kck said:

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.

You're right, I edit the log file because I didn't want to put my domain name,  it is indeed gaetanlord.ca . I did sent my last log file, and I only change the occurence of gaetanlord.ca

I have my own local resolver and it does resolv with this name on all the host inside my house. For the internet, it also resolv the same name. 

But your comment make me think a little bit more, I do not use default port 8123, so I trace the network and voila.

You assume that I use port 8123. In fact, I use port 80 or https port 443 via proxy.

So I edit file haremote.py and change the port to 80 and all is working fine, no more black screen, I can see the clock.

I then check if mqtt would work. The useage note do not mention username parameter for mqtt, after I look in the source code, I found out that you do have "username", so I also rcv console messages

But, I still have another question. I notice that disk space was decreasing, and found out that I collect a lot of data in the history buffer, almost every 2 seconds for the 5 minutes mention in your notes.  When looking at the error, it is about the HA connection where I do get a connection refused. Maybe you could help me out on that one too.

Log files includes, and not edited

 

 

 

log2 log1

[kck]

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.

 

[gaetanlord]

You're right, lot of message in Console.log. Shame on me not taking a look before posting.

As I mention in my previous post, I had to change the hardcoded port in haremote.py from 8123 to 80 to make it work, but with the error messages in HistoryBuffer

I just rescan the code and I found 3 other instances of hardcoded 8123 , that I missed inititialy,  in hasshub.py. I replace them with 80, my HA port, and no more messages. I think we found the problem.

I would love to help you in your code, but I'm a perl programmer and have to learn python, maybe one day. Great works. Now the fun begin

Regards

 

Console.log

[kck]

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

[gaetanlord]

Cool,

It will be a pleasure to test your new code, once ready

[kck]

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.

[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.