POE Smart

[RebusCom]

If you have spare devices kicking around, you can always plug them in with short jumpers to satisfy the idiot-proof test. The biggest challenge would be satisfying the 48VH with spare kit.

Is there a way to copy the config over?

The config can be copied over, but it sounds as though the settings would be changed as soon as the unit reboots afterwards unless it's pre-populated on the bench with the site configuration. That's a lot of extra equipment to drag out just to configure a switch and I'd have to always have enough spares of each type on hand (it's a mix). I could hurt myself in the process. Then how am I supposed to climb?

[lligetfa]

The way I read it, it is just that the UI would not let you set it if the idiot-proof req's were not met. The setting from before would persist reboots once the setting stuck.

As for staging, I was thinking more on the test bench, not the tailgate of the truck.

[sirhc]

First off we are looking at it not requiring a device to be plugged in to set the POE it just will not activate the POE until it detects the device and there is no cross short.

THIS IS A WORK IN PROGRESS!!!!

HOWEVER, lets assume that we would NOT let you turn POE until the device was present and all was OK, how big of deal is it to pre setup your switch with the POE turned OFF on those ports, then drive to the sit and install the switch then log into said switch and turn the POE on for the ports. It is not like the description would not be there telling you what is supposed to plugged into what port?

The whole idea is to prevent people from plugging POE devices into "LIVE" POE ports, THIS IS NOT SMART, especially on "new" cables runs or jumpers/ends you just crimped on hanging off a tower where people can make mistakes. Or if some one applies power and climbs the tower then goes crap there is no end on here let me just crimp one on of these RF45 ends on here...... ZAP - DEAD ETHERNET TRANSFORMER!!!

Now normally people have a ground guy or they have a NOC they can call into and say turn OFF POE on port 12 so I can swap this radio OUT.

OK then call call the NOC and say turn it back on.

Now normally we wanted people to run cable diagnostics BEFORE applying POE power which is why we put that feature in there to begin with but people just want to shot from the hip and say I almost never mess up an end so why bother to check it but if I do mess up I can just RMA the switch and say it came dead or just died. - OUCH

We are trying to come up with a solution that protects people from a bad day because of a simple mistake and us from a terrible bottom line.

POE Smart will be rolled out in an upcoming v1.3.0 release candidate, at first it will be optional until we are sure it works right then it will be on by default but you can still turn it off but eventually it may void your warranty from certain types of damage if you turn it off such as a Blown Ethernet transformer? - WORK IN PROGRESS

Pretty much Ethernet transformers generally only fail from dead shorts or lightning damage, by their nature they are not a part that wears out (magnetic coupling)

You might ask why is Ethernet Transformers used. The problem is that ethernet can support fairly long runs such that equipment on different ends can be powered from distant branches of the power distribution network within a building or even different buildings. This means there can be significant ground offset between ethernet nodes.

This is also why you MUST bond your tower ground system to your electrical service ground system!!!!

[JustJoe]

If you have spare devices kicking around, you can always plug them in with short jumpers to satisfy the idiot-proof test. The biggest challenge would be satisfying the 48VH with spare kit.

Is there a way to copy the config over?

The config can be copied over, but it sounds as though the settings would be changed as soon as the unit reboots afterwards unless it's pre-populated on the bench with the site configuration. That's a lot of extra equipment to drag out just to configure a switch and I'd have to always have enough spares of each type on hand (it's a mix). I could hurt myself in the process. Then how am I supposed to climb?

RebusCom makes a very valid point here. I envision that some of our remote sites will be relying on your switch to be providing power to the radio that will be connecting back to the NOC, and to other AP's that we would be trying to connect our laptop for local administration. Kinda hard to pre-configure a replacement switch with those "ON" back at the shop without attaching the same hardware.

Look, you are going to be testing POE enabled ports on power up and during port POE configuration enable each time regardless, right? Why create the hassle of overriding/changing the config? Why don't you let the "on" settings go and stay into the config regardless.

Then test, and if it doesn't pass the test, leave the POE off, mark the port "disabled due to error" in the WebUI .... but for that current power up cycle only.

Power cycling or doing a port diagnostic test will run the tests again, then if the device is there correctly it will pass the test, and it can just come up. If not, again leave it "disabled due to error".

Just as RebusCom mentions, there are times we will just hand a contractor a pre-configured replacement switch. We would not want the config self-modifying (BTW never a good programming practice for postmortem bug shooting). And in those cases. it might be easier/quicker for him to power cycle after attempts at correcting a cable fault and just watch for the POE lights to go on to check it.

Don't get me wrong, TESTING IS AN EXCELLENT IDEA! It's the permanent config change I found annoying.

And I am still holding out thinking it's worth trying to develop a low-current, low-processor-overhead "ohmmeter" type of test on a POE enabled but unplugged port. Because then you wouldn't just have POE Smart ... You could have a

POE Smartarrrr

[sirhc]

There are limitations that we have to work within as we did not design the core.

However how hard is it to configure the switch with all the POE turned OFF back at the office.

Then when you go on site and install the switch and log into it with your laptop the port descriptions should be enough information for you to know which ports get 24V, 24VH, 48V, or 48VH.

My guys have been installing these switches just fine for almost a year leaving the POE OFF until the switch is installed and the cables are plugged where they go when installed at the tower and then with their Laptop which they take with them to do installations at a tower they log into the switch going to the Ports Tab and just simply turning the POE on, after they ran a cable diagnostics if it was a new cable run of course.

Now with POE Smart if it is enabled on the ports it will automatically check the cable first so you will not forget to.

[JustJoe]

...

However how hard is it to configure the switch with all the POE turned OFF back at the office.

...

Now with POE Smart if it is enabled on the ports it will automatically check the cable first so you will not forget to.

OK, let's skip the ohmmeter idea for the time being.

How hard is it to leave it on then in the config file ?? The config does not live in the core does it?

You are going to test when the switch gets powered on. INDEED GREAT! At that point if it's not plugged in, just mark it *Error* in the GUI and don't turn it on. But don't change the config.

You are going to test when the user goes into port config and turns it on. INDEED GREAT! Well then set it in the config like the user wants. aaand again, At that point if it's not plugged in, just mark it *Error* in the GUI and don't turn it on.

The config then maintains what is intended, and POE Smart keeps us all out of trouble each time it checks. If the error condition is cleared next time it checks, it gets power. :)

On a cold and windy night replacing a switch, why would the tech need the laptop out? Why not let the switch do that simple task... the task which you will now have it doing anyway??

Let that sink in an think about it a minute before you are convinced that I must be wrong on my logic.

[sirhc]

Well for "now" POE Smart allows the user to configure POE for a port and if there is no cable plugged in it will not find a short and will turn it on so for "now" people are happy they can do what we do not want them to do which is plug "live" POE ports in.

How we envision this to be is POE can be configured ON and the switch constantly checks the cable diagnostics until it detect there is a cable and a device on the other other end and then turns POE ON and if they unplug it it turns it OFF but leaves it configured ON and the user can then plug the cable back in and it checks and then if OK it turns it back on..

HOWEVER the problem we are running into is a limitation with the cable diagnostics that I am trying to get VItesse to change:
1) Issue 1 is the switch will report a cable less then 1 meter as 0 feet so if the user has a radio plugged in with a 3' foot patch cable the switch thinks there is no cable but I have figured logic around this.

2) Issue 2 is some 1G devices report OPEN, OPEN, OPEN, OPEN on the pairs when the device is not powered up so we can not detect the device is there. Some 1G POE devices report properly as OK, OK, OK, OK "if" they are designed correctly.

3) Issue 3 is the way the core reports shorts, currently it reports pair shorts over cross shorts. For instance if you twist all 8 wires together it reports Short on all pairs and should report Cross Short. This is a hierarchy logic issue and I may get VItesse to change this.

For now POE Smart is being figured out in software and if needed worked around limitations beyond our control - WORK IN PROGRESS

[JustJoe]

Well for "now" POE Smart allows the user to configure POE for a port and if there is no cable plugged in it will not find a short and will turn it on so for "now" people are happy they can do what we do not want them to do which is plug "live" POE ports in.

...

OK, you have gone through a few revisions then, thanks for the additional explanation. But please consider this...

My last (mis?)understanding was that if at power up it found a POE enabled port as short or nothing plugged in, it would turn it off in the config.

And if at user port configuration time it found that port was short or nothing plugged in, it would not allow it to be configured.

Until you get the hardware limitation fixed, what I am saying is that let the user put what they want in the config, and don't change that.

But if the test finds short or not plugged in, either at power up or user config, then flag it as such in the WebUI, and don't turn it on until is later passes a test at power up, or they manually run cable test. (As opposed to continuously repeat testing like we would both apparently like to have).

That way you are protected until the hardware limitation gets a resolution?

Does that help explain what I was trying to say?

[sirhc]

And if at user port configuration time it found that port was short or nothing plugged in, it would not allow it to be configured.

Until you get the hardware limitation fixed, what I am saying is that let the user put what they want in the config, and don't change that.

But if the test finds short or not plugged in, either at power up or user config, then flag it as such in the WebUI, and don't turn it on until is later passes a test at power up, or they manually run cable test. (As opposed to continuously repeat testing like we would both apparently like to have).

That way you are protected until the hardware limitation gets a resolution?

Does that help explain what I was trying to say?

The test is not instant, it take 5 seconds and we do not make any changes from any tabs until Save/Apply is clicked which people LIKE the ability to go from Tab to Tab without losing config changes or having to apply each Tab before going to the next Tab so if POE is configured on a port that has a short we might as well set it back to OFF instead of creating a whole other set of POE Ports states/Flags.

Also I do not want to waste time creating logic that will get yanked out when we get the core function changed to what we need which will allow for the ability to yank and plug in ports at will LIVE without issues but I always want the port turned OFF when a short is detected. At that point the user should be looking at the UI/CLI and the switch Logs to see why POE was denied. (we log test results in the Switch Log)

[JustJoe]

Actually several things are clear to me now.