Any of you experience their hub start smoking just 30 seconds after it being plugged in? Tried different power cords and ethernet cables, nothing helps. The corner nearest the ethernet port gets hot, starts smoking, and underneath the plastic is slowly melting.
Reached out to support, hope they can help. Wanted to see if anyone else had a similar experience. Is this thing pretty much toast?
You sure it wasn't sexting? -- In humor. Not in humor. Do not even attempt to see if it will get better. Electrical shock and fire hurt. I saw a C-130 aircraft burn because an electrician dropped a wrench in the electrical panel.
I think she meant that I didn't spend weeks bulk moving devices. The whole "do it in batches of 10-20 devices at a time" is just voodoo science, and not really based on any technical requirement in the spec. The bursts of traffic you get from discovery frames or initial pairing is short lived - no reason to wait 24 hours between groups. I always migrate everything in one day if I have the time - 100 devices is doable in a half day (excluding time to rebuild automations/logic). 200 would probably take me a weekend, though.
Now, if you only have time to move a few at a time, that is fine too. My point is simply that it is not required to do so.
It is true that if you did a repair a few days after mass pairing, the devices may have had enough time to discover new routes to the hub. However, if you built the mesh from the inside out, existing devices should already have very reliable paths to begin with. And even without a repair zwave plus devices will rediscover a route if the existing ones don't work for some reason.
If you have a lot of non-plus zwave deivces, or the hub is doing a â– â– â– â– job building its path table, then yes in those scenarios going slow can help.
Building the mesh inside to outside (with the hub in the "center") makes good technical sense though.
More voodoo maybe but adding repeaters in an outward (from hub) pattern first seems to really help with the pairings of other devices. Not sure why exactly.
It can help. Anything that allows an end device build a good path back to the hub is helpful.
Always hard to say for certain, though, as radio waves don't always follow logical paths once you include interference, absorption, and reflection.
Also, zwave path selection is one of the parts of the spec that hasn't been released to the public yet, so the algorithm of specifically how it chooses its path is a little bit voodoo still.
Agreed. I'm sure there are probably hundreds of people ready to give Hubitat their money for this. And since Hubitat isn't a charity, I would expect that they would like to receive the money.
That makes me assume there are still technical issues with the service that are preventing them from selling it.
Again, as I have to assume Bruce (and/or any unnamed back end investors) wants money at some point, I trust they are working the issues expeditiously.
It would seem that there’s a problem with the C-7 in which if you plug it into a POE enabled port it it takes in power. Between what the charging port provides and what it then gets via Ethernet is starts to cook. Disabling POE stopped my hub from frying.
These are just assumptions here from me, so I’ll let the team speak to it, but it’s important to note what happened to me so that maybe I can help prevent someone from burning their house down.
EDIT: This was too cheeky / simplistic of an answer. See below for a more detailed answer.
Umm... Yeah... If you plug a non-POE device into a POE enabled port bad things happen. Lots if great stories of equipment meltdowns from this if you Google it.
No, I think you understood me fine. I just would’ve assumed that device negotiation would prevent something like this from happening. If the hub isn’t POE capable it shouldn’t be taking in power through Ethernet. Sounds like a design flaw to me, but I’m not the most educated on this topic.
Passive POE always sends power no matter what. Passive POE shiould always be left DISABLED and only turned on when it is confirmed the end device is POE capable.
802.3af/at switch ports, per the spec, should not send power unless it is confirmed the end device supports POE. Most people typically leave 802.3af/at ports in 'auto POE' mode.
That said, I've personally seen a few times in enterprise datacenters where the (very expensive, high end 802.3af/at) switch got it wrong - for whatever reason - and toasted non-POE end devices. Thus my recommendation to leave POE off on all POE ports unless explicitly needed.
I hear ya, and that all makes sense to me. I was just under the assumption that perhaps the device being plugged in to the switch, the Hubitat, would also play its part per some spec or design choice. Figured if this device is not POE capable it simply would not take in power via Ethernet for those rare chances in which the switch fails to negotiate properly and delivers power anyway.
But lesson learned for me here. The best advice I can take is to definitely turn off POE by default and manually enable it as needed.
Most modern POE switches are 802.3af or at. On those you should be able to leave it on, and just let the negotiation take care of things. So you aren't wrong - for anything other than Passive POE it should 'just work'.
But there are plenty of switches that also support putting ports in Passive POE mode (some ubiquiti switches for instance). Those you definitely need to be careful on.
In home environments I think it is just easier to leave it off, and turn it on as needed. It isn't the same as a datacenter where there are literally many thousands of ports to manage.