The problem with that, and with using Hub Information driver, is that you might get into a reboot loop. On my C-7, Hub Info gets bad data on its first poll after reboot. And I would expect that the hub sends out an ARP packet upon each reboot so that it can get its reserved IP, so the approach of doing a reboot if the IP is in the 169.254.x.x range might be made to work by an appropriate systemStart rule, but that could also put you into a reboot loop if the hub were to be booted with the Ethernet cable disconnected, etc.
A better approach might be to put the hub on a receptacle that has a pre-set turn-on delay, and plug that receptacle and the switch/router into the same source. I believe that such receptacles exist, our lab used to use them to sequence the turn-on of equipment. That would provide a delay before the hub boots.
Hi gopher.ny
I know that and that's why I'm asking for this feature.
I think it will be very easy to do and very useful and the same time.
Another users below are giving me good solutions but to buy a hardware with a timer is complicated here and I don't think is a good idea to make routines on the start process if this is something HE programmer can solve easily.
All that can be a solution .. it will make HE start double of the time needed but its a solution.
But I will preffer something implemented on the Hub core software.....it will be easier, faster, and less complicated for normal users.
You are right I thouth about it inmediately (I'm electric engineer so that's was my first choice) but telling you the truth we haven't those receptacles here....I can figure out how to make myself something like that with some circuits made by my own but too much trouble for something the HE programmers can solve easily. Don't you think?
No, I donāt think thatās necessarily true. Realize that the Hubitat platform is layered on top of a standard OS that Hubitat didnāt write. The network stack that does the ARP on boot to get an IP is buried in the networking stack initialize routines. Having done OS development, including a Unix 4.2BSD port to a new architecture back in the 1980s, Iām not going to speculate on the amount of effort that would be required, other than to comment that it would seem desirable that Hubitat run on top of as close-to-standard OS so that maintenance efforts would not be expended on such things.
But I would guess that, regardless of the amount of effort required, itās near the bottom of the Hubitat priorities. And, also, realize that you seem to be running a C-4, no longer sold, which does not have the same underlying OS as the current C-7 product. Any effort spent doing this for the C-4 would take away from product development on the current and future product line. Doesnāt seem to make business sense to me.
You might prefer it, but you very much have an "edge case" unique to your situation.
That makes it unlikely to happen
Thus, you need to consider realistic alternatives, such as what I suggested--else you'll likely end up with only a wish. As was just noted by others, a native HE solution just for you isn't likely.
Thinking in what you say it makes sense... I'm agree with you.
So.. I have to buy a new hub even when this one is ok or I have to implement solutions suggested here....good point from you, never thought "Hubitat platform is layered on top of a standard OS that Hubitat didnāt write", that's make things complicated.
