Two known issues that emerged over the last few days that I need to write up and address:
if you’ve set base_url in your configuration to a host that’s not accessible from your network internally, Konnected will not be able to reach the Hass API. Workaround: make a local hostname mapping on your router/firewall so whatever you set as base_url is accessible from inside and outside.
Does not work when api_password is set in the http module. No workaround yet.
I’m guessing this is the source of my trouble so far.
I’m not getting state changes at all.
will I rip a whole in space-time if I have 2 rpi’s running HA and I put the Konnected Component in both?
One is just for development and doesn’t have an API password. Might get me through until there’s a fix.
I have been testing this on a second raspberry pi3 and can confirm it works ok with API password set in the http section on hassio.
The base URL is not causing an issue for me as I have local loopback on my router but the upcoming changes are good as they will allow it to work if internet/dns is down.
Only thing I have noticed is that if duckdns or SSL is configured where base URL is set to an Https address then HA will pick up the initial status of the binary sensors but konnected can’t update them. You can switch any configured actuators like a siren and that works ok. The SSL/TLS problem is a big issue as lots of users will need this.
I have have been running 2 rpi3 with hassio and it doesnt seem to have broken anything. For me it just doesn’t update sensors on my main install that has duckdns configured. You can still switch actuators such as the siren from either system but the status doesn’t update on both.
I finally had some time to address this. I found that the api_password is actually not a problem as @Crhass determined, but setting base_url can pose a problem.
The solution was just merged in this PR: https://github.com/home-assistant/home-assistant/pull/14896
In the next release there’s a api_host configuration option that you can set in your konnected config. This should be set to the local hostname or IP/port if you’ve set base_url to something else. This will ensure that Konnected will only communicate with Hass over your local LAN
Hi Nate, not sure if you are aware but when https:// is enabled and set up for hassio, you can then only access using https:// and not http://
It still uses the same port of 8123 but disables http://
Konnected doesn’t seem to then be able to connect locally without https://
If another port could be used by home assistant for http:// for local Lan only even though https:// is enabled, it would work.
The MQTT server in Hassio accepts unencrypted connections but konnected would need to publish MQTT to this. Is this an option or can you get https:// to work correctly?
Ok, I wasn’t aware that http would also be disabled. However, there’s no reason why https shouldn’t work as long a valid certificate was offered by the Hass api server. Konnected does support https. In fact, SmartThings API is https exclusively and Konnected was originally built with SmartThings support.
So my question is … why is HTTPs endpoint not working? is there a certificate error?
Do you know what type of cipher the Hass api server is using to serve up https, or is that set up external to Hass?
Malcolm Lashley has posted more details on what he thinks may be wrong here. Have you seen it?
https://help.konnected.io/support/discussions/topics/32000001193
As for the cipher, the duckdns addon automatically sets up a letsencrypt certificate. The info from Chrome on my test install shows TLS 1.2, CHACHA20_POLY1305 and ECDHE_RSA as the key exchange mechanism. Does that help?
Thanks for that link. I’m embarrassed to say that I hadn’t seen that discussion yet.
I will take another look at this. I suspect it might just be a cipher issue. The Konnected firmware is compiled with a limited number of enabled ciphers to minimize memory consumption.
Thanks, Malcolm said he got a nodemcu to connect but not consistently, i got the impression that he also felt it was to do with memory. He said it seemed to stop working when heap size reduced.
Let me know if you want me to help test anything.
Hi,
I have just set my Konnected board up. The Binary sensors in HA are updating as expected. However I can’t get my siren to turn on. I have added the siren switch to my HA front end so I can easily switch it on and off, but when I do the siren doesn’t sound.
Unlike the instructional video my alarm system has several wires for the siren:
https://photos.app.goo.gl/PSs4p7e7fqKsg2bb7
Black = strobe
Blue = 0V
Red = Tamp
Green = Bell
White & Yellow = +12V
I ignored the strobe, 0v and tamp wires, and hooked up the white & yellow wires into the +12v port on the Konnected board. I put the green wire (Bell) into the - port as per the alarm instructions:
https://www.manualslib.com/manual/833866/Texecom-Veritas-8.html?page=13#manual
Here’s my HA config:
konnected:
access_token: blahblahblah
devices:
- id: 8F238
binary_sensors:
- zone: 1
type: door
name: 'Back Door'
- zone: 2
type: door
name: 'Front Door'
- zone: 3
type: vibration
name: 'Bay Window Sensor'
- zone: 4
type: vibration
name: 'Kitchen Sensor 1'
- zone: 5
type: vibration
name: 'Kitchen Sensor 2'
switches:
- zone: out
name: siren
Like I said the binary sensors are operating as expected.
I can’t think of anything I have done wrong, so why doesn’t the bell sound? Any pointers much appreciated!
Hi @Dan_Nuttall you must be in the UK. Your sirens configurations in Europe are a little different than here in North America. Try this, I think it should work:
White & Yellow: AUX/ALARM+ (middle black terminal on Konnected board)
Green & Black: ALARM-
Blue: AUX-
Red: probably not needed, but if the siren chirps at you, try connecting it to AUX-
Thanks Nate that did the trick! The red (tamper) wire wasn’t needed.
@heythisisnate
If you do get SSL for hassio to work with konnected.
If we connect to the api_host address, the certificate will then show as not matching the base_url. Will konnected still connect or will this be another issue?
This is great. I have it all set up and working with the Hass Custom Alarm. Many thanks for your efforts Nate!
I do have a couple of queries though:
Before I swapped to the Konnected board my alarm system beeped once when I opened / closed my front/back doors to make me aware someone had entered the property. It also beeped (slightly different sound to opening doors) every second after setting the alarm as the pending time counted down before arming it, and likewise it beeped every second upon entry as the warning time counted down before inputting the code. The sound came from a loudspeaker located above the keypad. It plugged into the old board +/- ports (you can see it on my photo from my last post). Is there any way of attaching this loudspeaker up to the Konnected board to perform the same actions?
The frequency of the siren was much faster on the old board. It is now equally as loud but it pulsates a lot slower which is less alarming! Is there anyway to increase the frequency of the siren?
Thanks
Hi Nate,
I have found that sometimes the Konnected component takes a while to load. To ensure that all the its entities (binary sensors) are are exposed to HomeKit I am trying to find a reliable method to check that the Konnected component has finished setting itself up. Is it possible to have it generate an event, say konnected.device_ready, when all of its sensors are good to go?
Thank you!
I have the same issue that the devices take a long time to discover in HA. Sometimes never (or at least over night). I emailed with Nate a few times and he indicated that a fixed IP for the boards and a corresponding entry in the HA konnected setup might work in the future to alleviate this. I hope that this can be implemented soon :).
In the meantime, I’ve considered creating a template sensor to check if another sensor exists or not and then link this new sensor to automatons I’ve set up. I would rather not spend the time if it is fixed soon however.
This is most likely caused by a delay in device discovery. Because HA doesn’t have any storage mechanism for persisting state between restarts, Konnected relies on discovery running every time after a reboot to re-discover the Konnected devices. There may be an event that the discovery component triggers that you can listen for.
As @ktdad mentioned, I’m thinking about a fix for this that would involve manually entering the local IP and port of the Konnected device(s) in your configuration so that the devices can be contacted immediately without relying on the timing of discovery. I think this will solve your problem as well as few other related issues.
I’m totally committed to improving this and making it work, but please give me some time to get it done!
Thanks @ktdad and @heythisisnate!
I’ve tried PLATFORM_DISCOVERED and it’s being announced for Konnected at least 4-5 times. COMPONENT_LOADED is too early. The others are pretty much unusable for my purpose. I guess I will wait for Nate to work on the fix, as long as its in the works. Thank you!