Use an ATT sim and you're good just need to hit their internal. You can have them map the sim to your network and setup it as an alternate route in the routing table. We did something similar at work for a backup to our backup.
but my public ips routing thorugh comcast would not route the att sim card.. thats why i only have the wifi switches on there so i can remotely reboot the comcast etc cable.. I would not be able to get to the mail/dns server.. or I would through its secondary private ip, but that would not help get it back up so mail could keep coming in etc.
I misunderstood, was thinking your main provider was att also.
as far as i know att does not offer public ip blocks, and even if they did not at 1g down I imagine.
my main router is expensive enough becuase i needed one that offered a bridging firewall as comcast puts your default gateway on the same subnet as your block so you cannot route you need to bridge. Not many support that.. I used to have custom dd-wrt to do it, but hardware got too slow to open and inspect every packet once i went over 200 meg speed.
Their business side does. I had a business fiber syncro for a while but the cost was prohibitive now given residential gig is going for $70 bucks.
mine is not cheap about 250 a month for 13 public ips, 1g down and 40 meg up. I checked into att and others there was nothing else avail in our town that was any good other than comcast.
I started with 2 54kb modems bonded, then went to single and dual isdn, then dsl, then cable.
i have a cloud core (mikrotik) router with 16 cores.. doesnt even work up a sweat now at full tilt.
i have about a 800 line firewall, and 32k ip address blocks.. in the router.
occasionally one of the address blocks causes issues like for discord servers when they are hosting in foreign countries
i still have the isdn modems and two us robotics couriers,, i really need to get a dumpster and get rid of a ton of stuff, like dlt tapes etc.
I ran into this with ubiquity a few years back. What drove me to put in all cisco hardware in the end.
pretty much the same path I took but I think my first were two 24kb (maybe 28kb i don't really remember that was back in the late 80's early 90's) zoom modems then went to 56.6k.
From the logs, there's some network device that frequently breaks socket connection. I've come across a handful of these over the last few days and added code in 2.2.4 to assign the blame to a particular device (it's always a device). It seems that socket device interface usage is picking up traction in the community, and I'll need to put some time into making it more stable.
There were also some weird looking zwave report messages which I forwarded to @bcopeland. He's a lot better at deciphering zwave stuff than I am.
5 Likes
I've scoured my logs, and only since this morning when I inadvertently unplugged a Harmony Hub device have I been getting socket connection errors (or really any errors at all, except for what I've mentioned above). I have since stripped everything out of my hub that was using IP, except for HomeKit integration (MakerAPI method). All I had previously using IP were CoCoHue, Harmony Hub and Sonos Integration, but I can afford to do without these in Hubitat for now.
Interesting I have quite a few IP socket driver's
My smart ups and send mail use telnet, the Tesla uses ip, I also have the hue and kasa switch and Honeywell API.
And off course open weather and dark and finally my eccowitt weather station. Weird I'm not seeing any issues with all those implementations.!
1 Like
Of course we do. First thing you could do is turn on all logging in the rule, and show logs of when it fails. You could also bear in mind that with thousands of users for a number of years, it's fairly unusual, although not unheard of, for these sorts of issues to actually be Rule Machine in origin. But, first thing is to see the logs for when there is an automation failure, and dig from there.
9 Likes
I realize I am replying to a two day old post, but the way you have your goodnight rule written, all your off actions are delayed 10s.
Each given line sets up its own 10s delay before executing but the rule continues and the next delay will get set up.
If you wanted sequential actions you should have the first delayed 10s and then the second one delayed 20s, etc.
Or put inline delays between off instructions of delay 10s.
Was done intentionally this way it hits them all at once. They are split up for ease of editing or modifying. On my phone when they are all on one line I can't see the whole line. The mesh and hub handle the load fine. Group optimization is enabled so not every device has to perform an operation. I originally had them staggered and worked backwards to tighter timings until I got all my mesh bugs figured out.
1 Like
I can vouch for this - my HVAC rules were pretty massive and I was getting frustrated when they would randomly misbehave. I literally cloned them a bunch of times and then chopped them each down into logical groups. They now work every time and the logic hasn't changed.
1 Like
What blanghor describes is exactly what I'm going through. I'm fairly certain I've narrowed it down to the c7 and not an insufficient mesh or bad device.
1 Like
I am seeing this as well on certain devices - I have a ZW+ GE switch for our bathroom fan that gets turned on when the bathroom shower light turns on. This has always worked pre-C7 but now have noticed it does not work on occasion - happened yesterday.
Also have a fake 5-way setup for my upstairs hall light. Our upstairs hall light is single pole with a Zooz V2 dimmer and the rest of the switches are Zooz V2 switches on power only with no load. This has never been a great solution (so do not recommend) but the sync "rule" has always worked albeit with some mild, acceptable popcorning. Under the C-7 it's very slow to sync all the other switches and sometimes fails to execute turning the light on or off at all except at the main dimmer. This usually happens once then subsequent tries after that work fine.
Anecdotally it seems when a device or maybe the system has been quiet for a while and then has to "wake up" is when slowness or erratic behavior is likely to occur. Again this is just speculation and have not done any real testing.
I wonder if the power saving measures of the ZW 700 series is causing an issue?
2 Likes
I've found the same. Simple rules that attempt to switch on/off lights that have been dormant for a few hours sometimes work, and sometimes don't. My logs show the triggering events are occurring, but dormant devices sometimes aren't getting the resulting messages.
1 Like
Same here. I've excluded and attempted to re-include a couple devices, and I did find one that didn't want to be re-included (keeps failing). While this is one of the devices I was seeing issues with ("Front Door Light" for those of you who were helping, the master side of a sync relationship between two lights), and I have received (but not yet installed) a replacement for the device, I am still seeing device delays (both initial control and status update), automation failures, and the like. That is, removing a seemingly problematic Z-Wave device DID NOT solve the issue, and my hub is as unstable and unreliable as it ever was.
I guess the only way to resolve the problem is to match up timestamps in the logs for all related parts (devices, rules, etc.) and see if there's, well, a problem. Honestly no one has told me what I'm supposed to be looking for, just that this information needs to be parsed so it can be shown that there's a problem. 
Well, there is DEFINITELY a problem, and I don't need to scour the logs to figure that out.
The fact of the matter is this seems like busy-work to get us chasing our tails while they try to figure it out. I was told that even if I prove that the problem is what it's suspected to be, there is no resolution until a firmware update is released that addresses the problem ("que problem," whatever that is), and there's no ETA for that update. I'm not saying there's absolutely no benefit to the research and findings, but there's no practical benefit to doing it now since there's apparently a firmware update coming at some point that allegedly solves this problem. BUT WHEN??
What a disappointment Hubitat has been. 
For those of us having major issues with Zwave, Hubitat should make an exception and push the beta firmware to us. I mean, how good of a test is it unless you include folks like us who are having major issues to see if it resolves those? I still have routes appearing in my zwave routing where the intermediate device in the route no longer exists. Surprisingly, most devices have been working "OK" lately, but I have yet to include many more Zwave devices for fear of messing that up.
1 Like
