Hi all, my sister got similar blinds to what I have that I control with WebThings (Bali), and after she failed to make three different commercial hubs stay working, I actually sent her to homeassistant first since this project gets little activity. But she wasn’t able to get homeassistant going due to router problems, so I sent her to webthings. Unfortunately she can’t seem to get the remote option working, even though it still works for me. She was able to create a domain and it lists the right one on her device, which she can get to locally. Is there a way to test whether her router is blocking traffic required? Thanks.
There is currenty am issue with the remote service, they arr working on it
You can always establish an SSH tunnel into your home network from a remote IP as long as you know your GW’s IP address (or have created a free ddns) and port-forward to the IP/port of the WT device. SSH does not rely on any external service and may be more secure.
I also installed Wireguard on my rpi/wt instance. It was a bit more complicated since I had to compile it into the kernel at the time but I think there is a direct apt install now. I prefer it and it seamlessly tunnels traffic to any host on my home network.
Thanks, I’ll give that a go and get it working so I can show my sister how to do it. @Martin_Verret it must be new person induction that has a problem; mine works fine.
Yeah the problem was for new, or reclaming domain
Absolute newb here.
How can I track progress on this “problem for new, or reclaiming domain”, as I’m probably running into it as well.
All roads in creating a subdomain appear to lead to “Error issuing certificate. Please try again.”
You can work locally until the problem is resolved. You should be able to get to the pi via the local ip address/name.
I am working locally trying to validate hardware that works and shows up to be added as things. But the system will be far less useful if I cannot access from outside the house.
Is there still an issue with the remote service. I can access my WebThing gateway locally but get the following error when trying to access remotely…
Hi @billfahle and @evanrobinson,
As @Martin_Verret mentioned, there’s currently a problem issuing free *.webthings.io subdomains due to a change made by our TLS certificate provider.
Please see this previous thread.
The issue is being tracked here and a fix has already landed but it will take a while for it to be packaged up into a new release.
In the meantime you should be able to access the gateway locally and/or use an alternative remote access mechanism.
The way I’d personally do it would be to use my own domain/subdomain and port forward to the gateway, but if you don’t have a static IP address that would require configuring dynamic DNS on your router. If you’d like to use your own domain/subdomain rather than a free *.webthings.io subdomain then there’s information about how to install your own TLS certificates in the README in order to make it secure.
Sorry for any inconvenience.
The current problem with the remote service is in registering new subdomains or reclaiming old ones. Accessing existing domains should be working as normal.
Can you provide any more information? E.g. a screenshot or error log?
Below is a snap shot of the last block from the error log…
The aforementioned error is shown when I try to login remotely. TLS Handshake seems to complete correctly. No issues with local logins.
INFO : Tunnel domain found. Tunnel name is: fleatechoz and tunnel domain is: webthings.io
2022-10-04 22:16:17.970 INFO : Tunnel name is set to: https://fleatechoz.webthings.io
2022-10-04 22:16:17.970 INFO : Local mDNS Service Domain Name is: fleatechgateway
2022-10-04 22:16:20.012 INFO : node-red-extension: 4 Oct 22:16:20 - [warn] [webthingsio-gateway:Local] WebthingsClient lost. Reconnecting in 5 seconds
2022-10-04 22:16:20.117 INFO : node-red-extension: 4 Oct 22:16:20 - [info] [webthingsio-gateway:Local] WebthingsClient connected
2022-10-04 22:16:25.020 INFO : node-red-extension: 4 Oct 22:16:25 - [warn] [webthingsio-gateway:Local] WebthingsClient lost. Reconnecting in 5 seconds
2022-10-04 22:16:25.124 INFO : node-red-extension: 4 Oct 22:16:25 - [info] [webthingsio-gateway:Local] WebthingsClient connected
2022-10-04 22:16:25.676 INFO : tasmota-adapter: Executed getStatus in 57 ms 
2022-10-04 22:16:25.726 INFO : tasmota-adapter: Executed getStatus in 107 ms 
2022-10-04 22:16:30.031 INFO : node-red-extension: 4 Oct 22:16:30 - [warn] [webthingsio-gateway:Local] WebthingsClient lost. Reconnecting in 5 seconds
2022-10-04 22:16:30.146 INFO : node-red-extension: 4 Oct 22:16:30 - [info] [webthingsio-gateway:Local] WebthingsClient connected
2022-10-04 22:16:30.687 INFO : tasmota-adapter: Executed getStatus in 63 ms 
2022-10-04 22:16:30.730 INFO : tasmota-adapter: Executed getStatus in 106 ms 
2022-10-04 22:16:35.044 INFO : node-red-extension: 4 Oct 22:16:35 - [warn] [webthingsio-gateway:Local] WebthingsClient lost. Reconnecting in 5 seconds
2022-10-04 22:16:35.152 INFO : node-red-extension: 4 Oct 22:16:35 - [info] [webthingsio-gateway:Local] WebthingsClient connected
2022-10-04 22:16:35.687 INFO : tasmota-adapter: Executed getStatus in 58 ms 
2022-10-04 22:16:35.741 INFO : tasmota-adapter: Executed getStatus in 112 ms 
2022-10-04 22:16:40.052 INFO : node-red-extension: 4 Oct 22:16:40 - [warn] [webthingsio-gateway:Local] WebthingsClient lost. Reconnecting in 5 seconds
2022-10-04 22:16:40.155 INFO : node-red-extension: 4 Oct 22:16:40 - [info] [webthingsio-gateway:Local] WebthingsClient connected
2022-10-04 22:16:40.696 INFO : tasmota-adapter: Executed getStatus in 64 ms 
2022-10-04 22:16:40.744 INFO : tasmota-adapter: Executed getStatus in 110 ms 
2022-10-04 22:16:45.060 INFO : node-red-extension: 4 Oct 22:16:45 - [warn] [webthingsio-gateway:Local] WebthingsClient lost. Reconnecting in 5 seconds
2022-10-04 22:16:45.164 INFO : node-red-extension: 4 Oct 22:16:45 - [info] [webthingsio-gateway:Local] WebthingsClient connected
2022-10-04 22:16:45.703 INFO : tasmota-adapter: Executed getStatus in 66 ms 
2022-10-04 22:16:45.751 INFO : tasmota-adapter: Executed getStatus in 113 ms 
2022-10-04 22:16:50.070 INFO : node-red-extension: 4 Oct 22:16:50 - [warn] [webthingsio-gateway:Local] WebthingsClient lost. Reconnecting in 5 seconds
2022-10-04 22:16:50.174 INFO : node-red-extension: 4 Oct 22:16:50 - [info] [webthingsio-gateway:Local] WebthingsClient connected
When I visit https://fleatechoz.webthings.io in my browser it actually says the certificate has expired.
Where do you see this error exactly?
When I visit my https link, the login screen will appear, as is expected, I enter my credentials (which work when in local mode) and the resulting response is the screen shown attached.
Huh, that’s an un-localised string. In English that would be “Username or password was incorrect”.
That error is generated here. It’s meant to be generated when you get the username and password wrong, but is also a catch-all for other errors.
What happens if you hard-reload the page (ctrl+F5) or clear your browser cache? Do you see a certificate error then? I have a feeling the TLS certificate on your gateway has expired but the login page is cached by your browser and when you click submit the login API call generates a certificate error which is being presented in the front end as a wrong username and password.
I hope that the current certificate authority problem isn’t preventing certbot from renewing certificates as well because if it is then we have a bigger problem than I thought.
I have done a Ctrl-F5 and this is what I get in return
And in addition, when inspecting the site cert…
If I “Accept the risk and continue” I can log in???
Login and password details have not changed.
I have tested on Firefox, Chrome and Edge. Same result on all.
Thanks for all you assistance.
Yes, that should be able to log in that way, but ideally you want to renew the certificate so you can be sure the connection is secure.
Are you able to access the command line on your gateway? You can either plug in a monitor and keyboard or enable SSH in developer settings.
The default username is “pi” and the default password is “raspberry”, but if you enable SSH you will be asked to change the default password.
If you are able to access the command line you can try manually renewing the TLS certificate following the documentation for certbot here https://eff-certbot.readthedocs.io/en/stable/using.html#renewing-certificates
$ sudo certbot renew
Please let us know if this works, and be sure to keep a record of any errors you encounter.
I’m afraid it turns out this doesn’t work, since certbot isn’t managing the gateway’s certificate.
Upon further investigation it appears that the known issue with registering new certificates is unfortunately also affecting the automatic renewal of certificates.
The existing fix for that problem should also fix this problem, but it hasn’t yet made it out to gateways as an over-the-air update.
Thank you for your patience while our volunteers work on making that happen.
Hi @bfrancis, I did a git pull from master today and built the docker container and ran it, but got the following in the logs still: 2022-11-14 17:04:20.995 ERROR : Failed to renew certificate: Error: Error finalizing order :: signature algorithm not supported
at AcmeApi.apiRequest (/home/node/webthings/gateway/node_modules/acme-client/src/api.js:54:19)
at runMicrotasks ()
at processTicksAndRejections (internal/process/task_queues.js:97:5)
at AcmeClient.finalizeOrder (/home/node/webthings/gateway/node_modules/acme-client/src/client.js:236:22)
at module.exports (/home/node/webthings/gateway/node_modules/acme-client/src/auto.js:148:5)
at Object.renew (/home/node/webthings/gateway/build/webpack:/src/certificate-manager.js:335:1)
However, when I ran it from npm start it worked!
A 1.1 alpha release which fixes this issue is now available for testing.