I’ve been having an issue where my heating system (Hive) is ignoring the commands from Hive themselves. So, switching off heating makes no difference. They receive the request, no issue there, but sometimes fail to send it to my Hive receiver, meaning my heating remains on. Their web dashboard and iphone app both show the request has been received (show heating off), yet the boiler continues to fire.
My setup utilises HA-Bridge (to create Alexa Smart Home Skills), Node-Red (to aid generating my entire home automation project) and IFTTT (for Hive only as they don’t officially provide an API, although there is a legacy AlertMe API which I am tempted to switch to, but it will have zero support from Hive themselves – although that might not be so much of a problem with their policy of denial).
Due to suspected issues with Hive not acting upon requests, I started logging all my requests in MongoDB. Unfortunately, it seems that there is an issue with Hive issuing these requests. I can see that my IFTTT requests are reaching Hive, as their dashboard on web and app both update. However, these commands are not reaching my boiler. Hive sent me a repeater to strengthen the signals on my system. As am in a one bed flat, I didn’t think this was necessary, but happy to add it to the mix.
It only took 5 days for the system to exhibit the same issues. A quick search on Twitter showed that others are getting similar issues, despite Hive saying “The Second Line team haven’t seen this issue before so they’ve asked me to do some troubleshooting and escalate the details to them.” .. which is strange, as I already reported this on March 22nd – just 5 days ago.
Amazingly, Hive claimed that Maker in IFTTT is “not supported” as they don’t give an example of its usage. However, it’s quite clear in the recipes I have already made where they show “works with hive”.
So, here’s my description of my system I gave Hive “Node-red dashboard on a local Pi creates an MQTT pub which is picked up on MQTT sub on AWS. This in turn is then captured by node-red on AWS and creates the http request to IFTTT. These stages are all confirmed by all parties (a local database logs the request, IFTTT shows the request and refreshing the hive dashboard confirms that the request has been accepted).”
According to Hive “Thanks Nick. We’re receiving 4 requests at once, something in your setup/code is incorrect.
All commands are coming from IFTTT, we may have to ask you to troubleshoot with the designers of Maker Webhooks.”
As a test, I changed the URL called from IFTTT to go to my local server, rather than call Hive’s IFTTT action. Each time, only one request, as expected. The first message is the MQTT request “myhive/HomeHeatingOffIntent/”. This is the incoming MQTT message from my internal Pi to AWS. Next is the IFTTT response from the http request – the “Congratulations” message. Finally, the output from the call to my test URL. A single call.
So, nothing is sending repetitive messages, and definitely not sending mixed calls as Hive believe.
“When the commands are being sent in multiples of four, the system is trying to respond to each command as it arrives, causing the system to remain on because it’s receiving the command to turn on four times, and also receiving a command to turn off.”
The system on my side is very straight forward, and is not possible to mix sending different messages without it being logged somewhere (especially at IFTTT).
I asked for proof of these messages, or timestamps of the messages – “The proof you’re asking for is the information I’ve advised can’t be disclosed Nick.” Commercially sensitive information – really? The time that my heating went on is commercially sensitive, I’m quite amazed.
After this stage, I have no more control or visual of what happens next, as it’s all on Hive’s side. I’ve proven everything I can.
Am now at the mercy of them escalating this, as cannot see how many people are using IFTTT and seeing this issue, let alone having zero access to any meaningful data via the methods provided to end users.