@ipodmusicman did you ever get it to work that you could add devices via the qwikswitch frontend? When I do they seem to disappear after a restart/upgrade of home assistant.
Also, was it you that complained about the fact that activating link mode was removed from the pi version of qsusb?
Regarding the add-on, grab the add-on that is on @nleroux’s Github page at https://github.com/nardusleroux/hassio-qsusb. When you install the add-on, you need to set up the various devices within the add-on config area. You cannot use the web interface to add devices.
Regarding the link-mode, you’re right. It isn’t part of the Pi version, but if you use the HTML pages from the Windows version with the Pi version, you get link mode. I confirmed this with Qwikswitch themselves. Sadly after many attempts to ask them to update the HTML pages within the Pi version, they have not done so. I heard via other sources that they are not putting any effort into their software at all so the chances of this happening are none.
I created a pull request on @nleroux qs-usb Github page to bring those HTML pages in, but he hasn’t merged in the changes yet.
@nleroux can you please do the honours and merge in the pull request that I created?
Hi Paul,
Correct, the html frontend for QSUSB is run from within the container, so changes made in html frontend will not be permanent and will not survive container restart.
Since the docker container is meant to be a standardised piece of software and all data should live outside of it, the way to make your devices file content permanent is to use the configuration blob under the add-on with hassio. This content simply gets populated into the devices file within the container upon startup.
There are examples of config, but if you want to use html frontend of QSUSB, do give it a go and view the new additions via the html interfcae in the devices file within container. Of course if you do not add the new devices in the add-on config section, then the new devices will not survive container restart.
I have merged the pr. I have not tested this pr so cannot confirm whether this is working or not. No environment to test this.
I am currently using test branch without issues for last year or more now. Next step would be to build docker container from test branch and publish to dockerhub and make add-on to be pulled from dockerhub instead of current local build.
If something else is required, maybe good time to fork project?
Any reason why you are not able to use the add-on on the master branch? I am using this with a Raspberry Pi 3b using with the 32 bit HA install as that is what was recommended at the time. I think it would be a advantageous to determine why the add-on on the master branch is not working for you in the first place and try to troubleshoot it. In the end, the add-on on the master branch, with the PR merged in, allows you to enable remote linking on QS relays, not to mention that the idea was to make the add-on multi-platform.
A friend of mine who is running a Raspberry Pi 4 has confirmed that the master add-on works 100% as well.
The biggest frustration at present is the lack of support from QS themselves in terms of issues with the QSUSB and believe me, I have tried over and over again. I am sure that you have found it crashing on you a few times when you try to turn on multiple relays at exact the same time. The same friend as mentioned above has started negotiations to even take over the QSUSB source code as QS themselves are not interested in maintaining it, but to no avail. But, we are still trying from our end to see what can be done.
I don’t really want to end up forking the project as there is nothing more frustrating for others when they find many versions of the same project and don’t know which one to use. I’ve referred many people to your project as this is the one that works very well. I would rather suggest that if you do decide to take a different approach re: dockerhub - assuming that the add-on will still be on your github repo, but you pull a docker image from dockerhub? then please include the additional www pages that you merged with the last PR. I would suggest taking the leanings from Frank - he is the HA add-on master IMO in terms of best practices and so forth … hence the changes I brought onto the add-on in the first place (multi-platform, etc).
Of course, if you need somebody to test, let me know.
Hi ipodmusicman, it is exactly the path I wanted to take with QS, why they just cannot make it a GitHub project I do not know.
I have also gave them a demo many years ago of my code to soft-link buttons with devices which allowed additional conditions to be set and evaluated. Sort of scenes on steroids. But to no avail.
Had issues before and hence moved to test branch. My platform has changed and not using hassos anymore.
I have installed add-on based on latest master and will monitor for a couple of days.
Hi ipodmusicman, is it possible to manually copy the /tools www files into the docker container until such time as I can get the master branch working?
I reverted back to the test branch and edited the config file to also copy www.zip. Activate link mode is now available.
QS also sent me the tools folder which has lots of other goodies, which is what I thought they gave you. I will see if I get time to include it as well to see whether it works as is. i.e. host:2020/tools
Then I am still stumped as to why the master branch fails for me. It seems to fail fairly quickly (around 5 seconds) so assume I forgot to set my architecture type in the example docker file.
Hi There all. Im new here and need some advice please…
Im stuch with the Qwikswitch Geyser controller as well as the Blinds Motor relay (QS-R2_S5). I cant get them to pick up as Entities in HassIO… I have tried many different YAML inputs but alas…
Has anyone came across the same issue and is there a fix?
@Obmeist3r as far as I understand the current implementation is essentially just a wrapper for the software QSUSB that QwikSwitch provides with the USB modem. So primarily limited to a lights platform with the option to define some relays a switches. i.e. relays and dimmers. Things like QwikCord’s, geyser controllers, blind motors, etc are not supported partly because QwikSwitch did not provide it and partly in the way the wrapper works.
Many requests have been made to QwikSwitch to add support for it in their the USB modem and not just in their cloud (QwikSwitch Bridge).
We either need to develop a new wrapper for the cloud. This is not ideal as you don’t want your automations to break when you lose your internet. (and also the reason I did not go down the Sonoff route.)
Alternatively we need to fork their USB modem web interface and add the missing units ourselves so it can also be supported in the wrapper we use in Home Assistant.
But @nleroux would be able to comment if my summary of the situation is correct.
(It is also not easy to develop support for something you do not own even if you felt like making the effort.)
My python skills are not good enough to add support for the devices I have.
Hi, @PollieKrimis is correct that existing hassio addon is just running the QSUSB modem software and web interface in a container. So same support that Qwikswitch have provided for QSUSB modem. I do not have any of qwikswitch newer devices so will not be able to comment on whether they can be made working from QSUSB modem or really need their Cloud bridge thing. The product pages only reference the Cloud bridge thing and talk was that they wanted to discontinue the QSUSB modem so would not hold my breath for any additional support on something they want to/or have discontinued already.
As an aside Sonoff devices flashed with Tasmota have been serving me relatively well and they don’t need to connect to any Cloud. The Tasmota firmware would send MQTT messages to your local MQTT broker which could be hosted on hassio.
I believe it is possible to add some of the components using the information in the QSUSB modem API, but that probably means we’ll have to get their permission to put it on GitHub.
But yeah, a lot of effort when a lot of people have already moved onto Sonoff gear.
I have a few Tasmota (Sonoff) devices but use it for non essential control as my wifi router has a tendency to hang and at the moment HA also hangs every other day which I’m struggling to pinpoint.
@nleroux I was hoping you could assist me here.
I have just installed Home Assistant on a rpi 3 and need assistance to get Qwikswitch working.
I have added the add-on following the github instructions and was able to start the add-on.
I then configured my relays within the configuration section and upon saving I was asked if I wanted to restart the add-on which I did.
From there I now don’t know what more to do.
I cannot locate any of the relays within home assistant what so ever, nor I have noticed does the “open web ui” command work. I cannot hit the qsusb website at all on the rpi3.
Here is a subset of the system logs, which I noticed:
21-04-22 21:37:05 INFO (MainThread) [supervisor.store.git] Cloning add-on https://github.com/nardusleroux/hassio-qsusb repository
21-04-22 21:37:08 WARNING (MainThread) [supervisor.addons.validate] Add-on config 'devices' use a deprecated format, the new format uses a list of paths only. Please report this to the maintainer of QwikSwitch USB Hub
21-04-22 21:37:09 INFO (MainThread) [supervisor.store] Loading add-ons from store: 67 all - 1 new - 0 remove
21-04-22 21:37:09 INFO (MainThread) [supervisor.resolution.evaluate] Starting system evaluation with state CoreState.RUNNING
21-04-22 21:37:10 INFO (MainThread) [supervisor.resolution.evaluate] System evaluation complete
21-04-22 21:37:32 INFO (MainThread) [supervisor.addons] Creating Home Assistant add-on data folder /data/addons/data/84bcc508_qsusb
21-04-22 21:37:32 INFO (SyncWorker_1) [supervisor.docker.addon] Starting build for 84bcc508/armv7-addon-qsusb:0.93
21-04-22 21:39:45 INFO (SyncWorker_1) [supervisor.docker.addon] Build 84bcc508/armv7-addon-qsusb:0.93 done
21-04-22 21:39:45 INFO (MainThread) [supervisor.addons] Add-on '84bcc508_qsusb' successfully installed
21-04-22 21:40:01 INFO (SyncWorker_3) [supervisor.docker.addon] Starting Docker add-on 84bcc508/armv7-addon-qsusb with version 0.93
21-04-22 21:40:02 ERROR (MainThread) [supervisor.api.security] Invalid token for access /host/info
21-04-22 21:41:38 INFO (SyncWorker_3) [supervisor.docker.interface] Stopping addon_84bcc508_qsusb application
21-04-22 21:41:39 INFO (SyncWorker_3) [supervisor.docker.interface] Cleaning addon_84bcc508_qsusb application
21-04-22 21:41:40 INFO (SyncWorker_4) [supervisor.docker.addon] Starting Docker add-on 84bcc508/armv7-addon-qsusb with version 0.93
21-04-22 21:41:41 ERROR (MainThread) [supervisor.api.security] Invalid token for access /host/info
Then here are the logs for the QwikSwitch USB Hub:
[s6-init] making user provided files available at /var/run/s6/etc...exited 0.
[s6-init] ensuring user provided files have correct perms...exited 0.
[fix-attrs.d] applying ownership & permissions fixes...
[fix-attrs.d] done.
[cont-init.d] executing container initialization scripts...
[cont-init.d] 00-banner.sh: executing...
-----------------------------------------------------------
Hass.io Add-on: QwikSwitch USB Hub
Add-on for the QwikSwitch USB Hub
-----------------------------------------------------------
Add-on version: 0.93
You are running the latest version of this add-on.
parse error: Expected string key before ':' at line 1, column 4
[23:41:41] ERROR: Unknown HTTP error occured
System: (armv7 / raspberrypi3)
Home Assistant Core: 2021.4.6
Home Assistant Supervisor: 2021.04.0
-----------------------------------------------------------
Please, share the above information when looking for help
or support in, e.g., GitHub, forums or the Discord chat.
-----------------------------------------------------------
[cont-init.d] 00-banner.sh: exited 0.
[cont-init.d] 01-log-level.sh: executing...
[cont-init.d] 01-log-level.sh: exited 0.
[cont-init.d] done.
[services.d] starting services
[services.d] done.
.
ENVIRONMENT - DOCKER BUILD
FILE=qsusb_pi_V1.91.zip
BUILD_VERSION=0.93
BUILD_ARCH=armv7
.
ENVIRONMENT - DOCKER RUN
SUPERVISOR_TOKEN=b2db2029d6b2ec88c0f1062bea816fd10f6402109257bed853b3bd782697fa0ad31aa509c4f12c90f0285219cf4f894d00712b9aa5538417
LANG=C.UTF-8
TZ=Africa/Johannesburg
HOSTNAME=84bcc508-qsusb
S6_BEHAVIOUR_IF_STAGE2_FAILS=2
S6_CMD_WAIT_FOR_SERVICES=1
HASSIO_TOKEN=b2db2029d6b2ec88c0f1062bea816fd10f6402109257bed853b3bd782697fa0ad31aa509c4f12c90f0285219cf4f894d00712b9aa5538417
PWD=/qsusb
HOME=/root
S6_LOGGING=0
DEBIAN_FRONTEND=noninteractive
TERM=xterm-256color
SHLVL=1
CWD=/qsusb
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
_=/usr/bin/printenv
.
DEVICES CONFIG
@1916f0/dim/Study
@0e7600/dim/Upstairs Passage
.
LS
-rwxr-xr-x 1 root root 78257 Mar 15 2016 /qsusb/QSUSB/qsusb
Starting
QSUSB V1.91
DEBUG=0
LOGS=0
Listening on Port: 2020
Devices Loaded:2
Crons loaded: 0
USB Found
USB Removed
USB Found