IOT frustration
Posted: Tue Feb 16, 2016 1:47 pmThis is doing my head in. I have this wonderful, virtually free micro-controller with WiFi connectivity sat on my LAN. Out there on the internet I have wonderful, free services - like IFTTT which could make my tiny micro-controller do great things like light lights, open garage doors, water plants... So long as I drill a hole in the firewall of my Router and forward a port into my LAN, and make my Router accessible to everything on the internet with a Dynamic DNS service.
OR I could make a TCP connection to an agent out there on the internet and leave the doors firmly shut. So that's what I've been trying to do. Trouble is, every approach I've tried has run into a pay-wall or roadblock of some kind. MQTT brokers in the cloud cost money and there's no way I can see of getting IFTTT to send a trigger anyway.
I did find one free messaging service called Dweet and things looked promising until I tried to get streaming access to dweets as describe here: IFTTT TRIGGERS USING DWEET.IO AS AN AGENT. This ran into the roadblock of not being able to keep a TCP connection alive with their server so only regular polling would work.
Then I wondered if I could set up some kind of simple message broker on my own cheapo shared VPS, hosting a domain that I could run some kind of agent on with a permanent TCP connection. Yet while I can easily get the IFTTT Maker channel to run a PHP script sitting on my VPS, the script can't POST to my ESP8266 either so I tried a long-polling hack where the ESP8266 issues a GET request to the script running an "endless" loop and receives chunks as and when real-time triggers come in.
Well, that works - for certain definitions of "endless". It seems the shared hosting won't allow PHP to keep a connection open for more than a few minutes, presumably to conserve resources.
I scanned around for other methods and found Gweet which emulates Dweet but is written in Go and has a far more sensible API. The author even put a demo up on appspot.com but guess what, the streaming calls return the message that the server won't permit "highjacking" (long-polling?).
Any suggestions kind peeps?
OR I could make a TCP connection to an agent out there on the internet and leave the doors firmly shut. So that's what I've been trying to do. Trouble is, every approach I've tried has run into a pay-wall or roadblock of some kind. MQTT brokers in the cloud cost money and there's no way I can see of getting IFTTT to send a trigger anyway.
I did find one free messaging service called Dweet and things looked promising until I tried to get streaming access to dweets as describe here: IFTTT TRIGGERS USING DWEET.IO AS AN AGENT. This ran into the roadblock of not being able to keep a TCP connection alive with their server so only regular polling would work.
Then I wondered if I could set up some kind of simple message broker on my own cheapo shared VPS, hosting a domain that I could run some kind of agent on with a permanent TCP connection. Yet while I can easily get the IFTTT Maker channel to run a PHP script sitting on my VPS, the script can't POST to my ESP8266 either so I tried a long-polling hack where the ESP8266 issues a GET request to the script running an "endless" loop and receives chunks as and when real-time triggers come in.
Well, that works - for certain definitions of "endless". It seems the shared hosting won't allow PHP to keep a connection open for more than a few minutes, presumably to conserve resources.
I scanned around for other methods and found Gweet which emulates Dweet but is written in Go and has a far more sensible API. The author even put a demo up on appspot.com but guess what, the streaming calls return the message that the server won't permit "highjacking" (long-polling?).
Any suggestions kind peeps?