You’ll note I’ve replaced the serial path with USB0, since that’s what’s reported on the console display when I plug the usb-to-ttl cable in the RPi USB port.
The explicit path under Raspbian is “/config/custom_components/visonic”, but I’m looking at the path through a terminal, which could be isolated in a Docker container (I’m still a LINUX neophyte).
I thought it might be useful to see what I can capture in the system log when I run a “CHECK CONFIG” operation. I ran it for about 10-20 seconds just to see what happened, and the following is what was captured:
I see references for the contents of “/usr/local/lib/python3.7/”. This directory does not exist; however, “usr/local/lib/python3.6/” does.
I can allow the CHECK CONFIG operation to run longer and I would expect it to capture more errors. That said, if the problem is the absence of the python3.7 library, we might need to start there.
It may be the version of python but it seems to be finding it somwehere as it’s tracing back.
/config is usually what the shortcut is set to inside a docker image, this is mapped to somewhere on your filesystem outside of docker. So, if you are inside the docker image the path will be /config/… if you are outside the docker image it will be whatever directory is mapped to /config with docker.
But it is the end of the log file that confuses me
File "/config/custom_components/visonic/__init__.py", line 7
<!DOCTYPE html>
^
SyntaxError: invalid syntax
This is clearly the init python file for my component and it imples that the file is corrupt or has been over written by something as an html file. That is certainly not the content of my python file. Is it possible that you can look at that file and check its content, does line 7 contain that html line.
Yes, it’s in the file. In downloading the files, I obviously did something wrong. I’ll download it a different way and ensure it’s in the source format.
I should point out there is no serial connection between the panel and the Rpi at this time; I assume getting a clean configuration check would be a prerequisite. If this is not correct, please let me know.
I must admit that I’m out of my depth here, I don’t really undestand the differences that Hassio makes to loading external Components. So the rest of this post is assumption and guesswork on my part.
I would think that you are correct, getting a clean config check would be a prerequisite. However, that may not be the case!
I assume that when it does a config check it tries to initialise at least the main body of the python files, checks that all imports (the HA requirements and dependencies) are available and that the configuration.yaml file items are valid. When it check the configuration file parameters (like ethernet, motion_off, language) it must elaborate the main python bodies without calling the platform setup functions.
As it calls the body of the init.py (double underscores make it go bold), line 98 calls the asyncio function to create a queue. The config check may not set up the asyncio environment the same way that it does when it’s going to run the Component properly. Although I can do a config check and it passes, it may be different in Hassio.
I’m hoping that someone else that has Hassio can help out more than me. This needs someone who understands the innards of HA and how Hassio works.
So getting a clean config check may not be necessary. Have you tried loading the component, now that you know the files are correct?
I’ve been poking around to understand how Hass.io differs from other deployments. From what I’ve read, the implementation is designed to control the configuration to make system integration predictable and simple for the majority of users. That’s why add-on elements are vetted and available from a repository. If one would change anything in the Docker container (such as python libraries), there’s a chance it would break Hass.io.
Custom components can be added, but I believe all dependencies must be in the ~/custom_component directory (and sub-directories). Since nearly every element of Home Assistant is a python script, Hass.io dependencies (such as additional python libraries) should be included with the custom python scripts in custom_components. With LINUX and perhaps Hassbian, library dependencies are found where it lives in the OS.
I hope someone who’s more knowledgeable can tell us. I’m still pretty low on the learning curve.
I’ve only put the visonic component in the configuration.yaml file and ran a configuration check. The resulting output with the correct files was attached to my last post. Since there are still issues with what I’m guessing are dependency references, I was hoping to isolate and reconcile these before committing to loading the component. The last time I did that, I had to perform a restore. I know it’s not that difficult, but I’d like to figure out what’s not being located and attempt to see if at least one or more of the references can be reconciled by putting them with the visonic components. Failing that, my next step might be to deploy HA using LINUX or Hassbian.
I can report progress. I just loaded the component and validated the configuration. Now I get three “Download Timer has Expired, Download has taken too long” messages in the log. I need to get the alarm panel in an operational state.
I can enter either mode with the force_standard:’ configuration entry. Moreover, I’ve yet to see any difficulty with serial operation using this USB-to-TTL adapter:
The adapter has 3.3V logic output, which directly plugs into the alarm panel. I do see 22 seconds of the repeated command ‘Sending Command (Ack) raw data 0d 02 fd 0a’ proir to Powerlink enrollment, but it’s not clear to me why this is necessary.
The only other thing I had to do was specify ‘/dev/ttyUSB0’ in the configuration. The console output of the Rpi indicates the port when the USB adapter is plugged in.
I think that this will be the “info” log entry for downloading the appropriate parts of the panels EEPROM. If you could set the logging to debug (or replace all “log.debug” with “log.info” entries in pyvisonic.py) then you would see a lot more. So I think that is normal.
That adafruit adapter is worth the 10 dollars, looks good and easy to use and set up.
Did you have to do anything that would be specific to a Hassio install, just to potentially help others?
Well, Hassio is my only basis of reference, so I can only guess. I can mention what I learned in the process…
I leaned heavily on the capabilities of the Configurator add-on. I don’t know if the add-on is unique to Hassio. Specifically, I used it to make the custom_components directories and transfer the files from the GitHub site. I ultimately downloaded the Zip file, unzipped it, and then uploaded each file to the Rpi. My initial attempt downloaded the Raw file, which was corrupted with HTML formatting tags. I didn’t expect that.
I learned that the configuration check would not work until the component was loaded. Loading it required a leap of faith, at least for me. Thankfully, doing so did not corrupt the Hassio installation to the point where I couldn’t use the browser interface. I was pleasantly surprised when I checked the configuration and it was valid.
The last thing I’d add is a warning to not connect the red wire of the USB adapter to the alarm panel. It’s a +5 volt output and could damage the panel. Just tape or tie it back to the cable; I covered it with shrink tubing and tied it back using lacing cord.
Good morning Pocket,
I’ve been reading your progress and it seems super to me that you’ve been able to get Dave’s component in Hassio to work.
Could you create a “manual” on how to proceed?
Right now I am in the stage where the validation of the configuration is left me thinking and does not validate it.
I created the folders using the configurator add-on, downloaded the component zip, unzipped and uploaded to the corresponding folder.
Thanks in advance
Edit: Now it works in Hassio !!!
For now only tell me this!
2019-03-27 17:02:03 WARNING (MainThread) [homeassistant.loader] You are using a custom component for visonic which has not been tested by Home Assistant. This component might cause stability problems, be sure to disable it if you do experience issues with Home Assistant.
2019-03-27 17:02:10 ERROR (MainThread) [homeassistant.components.device_tracker] Unable to load /config/known_devices.yaml: Config file not found: /config/known_devices.yaml
2019-03-27 17:02:10 WARNING (MainThread) [homeassistant.loader] You are using a custom component for visonic.alarm_control_panel which has not been tested by Home Assistant. This component might cause stability problems, be sure to disable it if you do experience issues with Home Assistant.
2019-03-27 17:02:11 WARNING (MainThread) [homeassistant.loader] You are using a custom component for visonic.switch which has not been tested by Home Assistant. This component might cause stability problems, be sure to disable it if you do experience issues with Home Assistant.
2019-03-27 17:02:55 WARNING (MainThread) [homeassistant.loader] You are using a custom component for visonic.binary_sensor which has not been tested by Home Assistant. This component might cause stability problems, be sure to disable it if you do experience issues with Home Assistant.
Here’s a first attempt. I apologize if it is too simplistic for you, but considering the language barrier, I figured the more pictures, the better. Please rename the file to remove the ‘.yaml’.
I’m experimenting with the panel and the Powermaster Component, primarily to understand if things are working as expected, and to learn the features and behavior of the PowerMaster 10 G2 alarm panel. In doing so, I got into a strange lockout state, where the panel displays Ready (with a green light) and the HA badge displays “TRIG” (triggered state). In that condition, HA logic still thinks the panel is armed because the disarm button is displayed when I click the badge. When I click disarm, nothing happens–no state change.
Do you think there are some states this panel has as compared to earlier models? Is there anyone else here who uses the same alarm panel? Is there some reset command I can use get back to a known condition?
If you replace all “log.debug” with “log.info” in pyvisonic.py and upload your log file I can take a look through to see what is happening. I know that the last log file from UffeNisse showed an A7 message that I do not know how to decode, yours might be similar.
And well done again for all your efforts on the Hassio setup
I’ll try to capture the logs with the “info” option. Hopefully, I can recreate the problem. It did leave me thinking about how to make a state transition diagram for the states and modes, just to see if there are any inter-dependencies. In my mind, going from arm to disarm should put much of the logic (in the python scripts) into a known state. Still, that assumes there is a working disarm button!
A related issue might be that the HA logic (Visonic Component) is not keeping synchronized with the state information in the alarm panel. When I restarted the HA server without touching the alarm panel, I regained control of panel functions. So, I’m thinking there could be illegal states that enter from logical hazards (think race conditions) but have no way to exit to a legal state without re-initializing.
Thanks. I guess I experienced a prick of conscience and felt the need to give something back to the HA community.
