I've programmed buttons on a Hub LR with an Internet Request posting a JSON message to one of our servers. It worked as intended.
Came back a few weeks later, didn't work anymore (no changes). Added a second button with similar programming, also not working.
I reset the hub, programmed one, working again. Programmed 29 more in a similar fashion, moved the hub out to production within 10 minutes (so with a power cycled), and none of them worked anymore.
Thinking the hub is bad, I tried the same with another hub, and first it's working, programmed 10 buttons, after power cycle again not working. Tried "jump starting" it with various methods, like adding more buttons, removing, changing settings, no luck, The hub itself seems to register the button push as the LED flashes and the button icon in the app wobbles.
When using the SDK to submit a similar request on a "working" hub (essentially the example from the SDK tutorial at https://hubsdk.flic.io/static/tutorial/), it also works fine and I get status code 200 back, as expected.
When I run the same code in the SDK on a "malfunctioning" hub I get this error as a result:
TypeError: cannot read property 'statusCode' of undefined
at [anon] (duktape.c:56634) internal
at [anon] (root/test1/main.js:37)
at handleResponse (http.js:62)
at handlePacket (pipe_communication.js:56)
at readCallback (pipe_communication.js:93) preventsyield
Anybody experienced something similar to this?
We have a bunch of other flic hubs in use that do not seem to have that problem. I'm not sure if it's something I am doing, but the only action between it working and not working is a power cycle. Quite annoying and ready send 16 packs of buttons back to them.
@alces as you can see on https://superuser.com/questions/1581627/where-is-my-lan-hostname-stored, hostnames on the LAN is not really a "basic feature of networking" since there are like four different "standards" for that. Currently, the only thing you should rely on is that you use a FQDN that the DNS resolver the DHCP server gives the hub will resolve.
@Emil Yes, computer name on the network. Does that mean you essentially have not implemented one of the basic features of networking? Although it seems to work in the beginning for some time?
Is that then trye for using the FQDN, as well, and I can expect this stop at any random time?
@alces with hostname, do you mean the computer name on the local network? In that case, it's not something we support currently so don't expect it to work.
@Emil Another update. Working with our networking team to see if requests to the name server may get blocked at some point (they don't), they suggested to try the FQDN, and that also worked on the "broken hub". So it seems after some time hostname only does not work anymore, something about how the received DHCP options are handled maybe? Would explain that it stops working after a power cycling.
@Emil ok, with the changes in the code I get a more descriptive error:
request status:
Unknown hostname: ourserver: Temporary failure in name resolution
undefined
When i put the IP address in the request, it works.
While this is a name resolution issue now, I still think it is somehow hub related. Having another (still working) hub on the same switch, that still works using the host name, while the "broken hub" has the name resolution problem (and none of our few hundred other pieces of equipment have a name resolution issue either).
I can work around this for now using the IP, but it sounds like there might be some issue with the hub (firmware).
We have updated the example code so this error being thrown should not happen anymore.
@alces the example is a bit simplified as it does not handle the error case. If the request couldn't be made, res will be undefined and err will contain the error. Could you possibly tell what the err parameter contains?
@alces the example is a bit simplified as it does not handle the error case. If the request couldn't be made, res will be undefined and err will contain the error. Could you possibly tell what the err parameter contains?