Turn.it to debug. Save post the logs then bacj off save again
The choices are "off", "minimum", "maximum" I will assume debug == maximum. I did one of three units. I will see what happens.
I believe I did what you asked. Toggled to maximum. Hit save preferences. Then toggled to off and hit save preferences. The iterative logging loop continues.
I did notice one thing. The "upsStatus" in the state variables is blank and the UPSStatus in the current state variables is populated. See the attachments
i already commented previoiusly that is not debugging those 5 lines are info and come out every run.. in addition, no matter what you do the warning will come out as that is internal to the telnet library..
Then what is the point of "OFF" as a setting for logging. Off should mean all logging. These should be included in the minimal level IMO.
it means off for all debugging
EDIT: Disregard - reminder to everyone to not forget to check your firewall settings!
I just picked up an SMT1500 and AP9631 as @kahn-hubitat suggested a few days ago. I can access it fine through my browser, but I can't get the driver to connect. Have reentered the password multiple times. Any advice?
1 Like
I realize that I'm very late to the party, but could the [a] driver be designed in such a way that it could actually control the SMT1500 - specifically switching the outlets on/off?
I was thinking about setting up a rule that when the battery got to X, my UDM Pro would shut down, but, but it would need to have the power cut to it otherwise, when the power comes back on, it would still be in the shutdown state. This could obviously be done with a smart plug, but if the SMT1500 can act as a "smart plug," all the better.
EDIT: Answer appears to be yes. I'll work on it...
1 Like
OK, I give up. In the past I was able to add the Notification capability and send telnet commands, but that isn't working here (maybe because of the username/pw requirements - my other device didn't have a login).
It just needs 2 commands: ups -o 2 off and ups -o 2 on (optional to add the 1 group as well) but I can't get it to work on the Hub (works fine in a regular terminal). On the SMT1500, '2' is the Group 1 outlets and '1' is the Main outlets.
I.can work.on it but not.for a.month unless you give me remote access. I am away from home and cannot risk screwing up my ups's that are currently online.
Nah, no rush. I might keep trying too. My "give up" was probably hyperbole and just meant, give up for now.
This is not the first time that I've wished that Hubitat had a little more user-friendly telnet interface (or even just a generic driver for sending telnet commands).
Not sure if this helps but, I do have this bookmarked:
Thanks. I'm still not exactly sure what to do with the UN/PW aspect, but I'll keep this around for some of my other integrations for sure.
here is a version for testing
commands avail are on, off , reboot for both the entire ups or an outlet group..
1 Like
Wow. Thanks. That was quick.
I only own the SMT1500, so this might be relevant only to that particular one, but here are the changes that I made to your code to lines 112 (just description) and 114 make it make more sense for my setup:
I was surprised that Group 1 per the outlet bank labeling/web portal was outlet group 2 in the telnet commands when I tested it, but it is.
So Main = 1
Group 1 = 2
I'm not sure if it has to do with the speed at which I was trying to send the on/off commands while testing, but there were a couple of times that I had to send the command twice before it would work. Also, I noticed this in the logs. The Got Failed messages don't correlate with the On/Off commands working or not, they just pop up every time:
i cannot turn mine off to test as i said.. i did test trying to turn on when already on.. mine smt1500 has three banks maybe 0 is the entire ups.
apc>ups -o 0 on
E100: Command Failed
apc>ups -o 1 on
E100: Command Failed
apc>ups -o 2 on
E100: Command Failed
apc>ups -o 3 on
E102: Parameter Error
Usage: ups -- Initiate UPS C
to me the output sure looks like it is failing. are you sure it is working..
Yep, I'm positive. I'll have to mess with Group 0 tomorrow.
Here are my logs. Starting from the bottom (yellow) the off command worked. In the middle (red) I sent an on command and it did not work, then at the top (yellow again) I sent another on command and it worked.
Oddly, the 2 commands that worked have the "Got Failed" message, but the one command that did not work did not.
Oh, and here are my APC logs to show you what I mean about 2=Group1
Here is a summary of my testing this morning - learned some stuff about how the UPS works, so that's nice:
- I put the outlet group 0 back into the code and tried the on/off commands - nothing happened at all. Verified this with telnet commands from a terminal as well. So for my UPS/driver instance, 1 and 2 are the only ones that I can use.
- Determined via both telnet and your driver that the outlets labeled Group 1 (which are actually o2) cannot be powered ON unless the Main group is on (o1).
- Therefore, turning off the Mains group (o1) also turns off the Group 1 outlets (o2); however, turning on the Main outlets (o1) does NOT turn on the Group 1 outlets.
I'm still not exactly sure what the "Got Failed log messages" are all about. When I send the exact same commands via the terminal, this is the output I get:
I also verified via the web portal for the UPS the abovementioned outlet behavior. Note that with the Mains off, the Group 1 outlet commands are greyed out:
And sending this command:
results in both groups being turned off:
In summary, thank you very much for making these additions to your driver - they are very helpful to me, but if you publish it in the official repository, you'll probably need to expand line 114 of the code to include '2' (or maybe even others) and your readme will probably need to have some "YMMV" disclaimers warning people to test to see which outlets are controlled by which commands.
The only other question that I have (and this is just for my knowledge as I tinker with drivers like this) is why the driver seems to have to log in for every command? Couldn't the Hub just stay logged in to reduce the number of commands being sent? You'd probably have to include a setting for the UPS Session timeout (I have mine set to 60 minutes) and then just have the driver login every x minutes.
Again, that's not really a suggestion as much as it's just a curiosity.
-
No the ups logs you out within like 30 secs and often on off commands immediately. So needs to log in each time.
-
I have duplicate/two commands for each option... as it was not overly reliable. The second could be causing the failure message as it logs a failure trying to send the cmd when it is already in that state. You can try removing one or just ignore it. I will test more fully when i get home near my ups's end of may.
I will also look at setting timeout and playing with trying to stay logged in with a timer.
