Re: [Nut-upsuser] APC BACK UPS 2200 model BZ2200BI-BR (New output)

[Charles Lepple]

On Fri, Sep 11, 2015 at 10:54 AM, Mario Lobo  wrote:
> I know the battery is fully charged and that the load is more than 7.2%.
>
> The battery voltage seems correct.

Mario,

I realize some of the variables are not yet correct, but is this
better than before? I would like to merge the solis_debug branch in to
the master branch.

Bruno,

Any ideas? Mario mentioned his model is getting mis-detected as a Solis 1.0.

-- 
- Charles Lepple

___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] APC BACK UPS 2200 model BZ2200BI-BR (New output)

[Charles Lepple]

On Sep 11, 2015, at 8:11 AM, Mario Lobo  wrote:
> 
> On Thu, 10 Sep 2015 22:31:08 -0400
> Charles Lepple  wrote:
> 
>> On Sep 9, 2015, at 2:06 PM, Mario Lobo  wrote:
>>> 
>>> By the constance of header and footer bytes, I think something
>>> different is going on now.
>> 
>> Right, this is the resync code that @rpvelloso suggested.
>> 
>> https://github.com/networkupstools/nut/issues/231#issuecomment-138971923
>> 
>>> It still identifying as a Solis 1.0 (which is not) but at least it
>>> is doing it on its own, without gdb.
>> 
>> If I remember correctly, Bruno was mainly looking for OB/LB status,
>> so he mapped the APC model to the nearest Solis model. I've CC'd him
>> in case he has any other insights.
>> 
>> Bruno, the mailing list thread starts here:
>> http://article.gmane.org/gmane.comp.monitoring.nut.user/9306 and
>> here: http://article.gmane.org/gmane.comp.monitoring.nut.user/9317
>> 
> 
> Charles;
> 
> Do you think I could try this solis with nut and see what comes up?
> 
> Or you think it is not worth it yet?

The only way we will know if this works is if someone tests it...

It looks like the low-battery signal is calculated from the charge. I am not 
sure what effect the incorrect voltages will have on that calculation (I have 
not seen any numbers) but if they are all off by a constant factor, it should 
work.

-- 
Charles Lepple
clepple@gmail




___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] APC BACK UPS 2200 model BZ2200BI-BR (New output

[Charles Lepple]

On Sep 9, 2015, at 2:06 PM, Mario Lobo  wrote:
> 
> By the constance of header and footer bytes, I think something
> different is going on now.

Right, this is the resync code that @rpvelloso suggested.

https://github.com/networkupstools/nut/issues/231#issuecomment-138971923

> It still identifying as a Solis 1.0 (which is not) but at least it is
> doing it on its own, without gdb.

If I remember correctly, Bruno was mainly looking for OB/LB status, so he 
mapped the APC model to the nearest Solis model. I've CC'd him in case he has 
any other insights.

Bruno, the mailing list thread starts here: 
http://article.gmane.org/gmane.comp.monitoring.nut.user/9306 and here: 
http://article.gmane.org/gmane.comp.monitoring.nut.user/9317

-- 
Charles Lepple
clepple@gmail




___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] APC BACK UPS 2200 model BZ2200BI-BR (New output

[Mario Lobo]

On Tue, 8 Sep 2015 22:25:54 -0400
Charles Lepple  wrote:

> @rpvelloso on Github suggested some changes (driver version v0.64)
> that should help with the initial sync:
> 
> https://github.com/networkupstools/nut/commit/debc8e0280ea4de9a0db5ca34aa66705b285f61f
> 
> It's the solis_debug branch on Github.
> 
> Does that help? I'm concerned that it might get out of sync later,
> but I don't want to change too much at once.


Hi Charles !

By the constance of header and footer bytes, I think something
different is going on now.

It still identifying as a Solis 1.0 (which is not) but at least it is
doing it on its own, without gdb.

Here is the output:

/usr/local/libexec/nut/solis -a lobos -u root -D -D -D 
Network UPS Tools - APC/Microsol Solis UPS driver 0.64 (2.7.3.1)
   0.00 debug level is '3'
   0.001843 getbaseinfo: sending CMD_UPSCONT and ENDCHAR to sync
   1.330248 getbaseinfo: received 25 bytes from ser_get_buf_len()
   1.330283 CommReceive: RecPack: (25 bytes) => bb 47 88 ad 1b 0a
a0 18 02 30 14 10 0b 1.330298  00 00 00 01 00 09 a1 49 5e 5e 25 fe

Detected Solis 1.0 on /dev/cuaU0
UPS Date 1999/10/09
System Date 2015/09/09 day of week Wed
UPS internal Time 16:20:48
Shutdown programming not activated

   1.330381 getupdateinfo: requesting 25 bytes from
ser_get_buf_len() 
2.414226 getupdateinfo: received 25 bytes from
ser_get_buf_len() 
2.414259 CommReceive: RecPack: (25 bytes) => bb
46 88 ac 02 0a a0 09 02 31 14 10 0b 
2.414274  00 00 00 01 00 09 a1
49 5e 5e fc fe 
2.414566 dstate_init: sock /var/db/nut/solis-lobos
open on fd 5 
2.414600 getupdateinfo: requesting 25 bytes from
ser_get_buf_len() 
3.499203 getupdateinfo: received 25 bytes from
ser_get_buf_len() 
3.499237 CommReceive: RecPack: (25 bytes) => bb
46 83 ac 03 0a a0 09 02 32 14 10 0b 
3.499253  00 00 00 01 00 09 a1
49 5e 5e f9 fe 

4.436557 getupdateinfo: requesting 25 bytes from
ser_get_buf_len() 
4.585178 getupdateinfo: received 25 bytes from
ser_get_buf_len() 
4.585209 CommReceive: RecPack: (25 bytes) => bb
47 83 ad 19 0a a0 0c 02 33 14 10 0b 
4.585224  00 00 00 01 00 09 a1
49 5e 5e 15 fe 
6.440663 getupdateinfo: requesting 25 bytes from
ser_get_buf_len() 
6.440711 getupdateinfo: received 25 bytes from
ser_get_buf_len() 
6.440731 CommReceive: RecPack: (25 bytes) => bb
46 83 ac 1b 0a a0 1e 02 34 14 10 0b 
6.440745  00 00 00 01 00 09 a1
49 5e 5e 28 fe 
8.482557 getupdateinfo: requesting 25 bytes from
ser_get_buf_len() 
8.482601 getupdateinfo: received 25 bytes from
ser_get_buf_len() 
8.482620 CommReceive: RecPack: (25 bytes) => bb
46 82 ad 1a 0a a0 20 02 35 14 10 0b 
8.482636  00 00 00 01 00 09 a1
49 5e 5e 2a fe 
10.485513 getupdateinfo: requesting 25 bytes from
ser_get_buf_len() 
10.48 getupdateinfo: received 25 bytes from
ser_get_buf_len() 
10.485575 CommReceive: RecPack: (25 bytes) => bb
46 83 ad 19 09 a0 02 02 37 14 10 0b 
10.485590  00 00 00 01 00 09 a1
49 5e 5e 0d fe 12.513556 getupdateinfo: requesting 25 bytes from
ser_get_buf_len() 
12.513599 getupdateinfo: received 25 bytes from
ser_get_buf_len() 
12.513619 CommReceive: RecPack: (25 bytes) => bb
46 87 ad 01 0a a0 31 02 39 14 10 0b 
12.513634  00 00 00 01 00 09 a1
49 5e 5e 2b fe 
14.533025 getupdateinfo: requesting 25 bytes from
ser_get_buf_len() 
14.533089 getupdateinfo: received 25 bytes from
ser_get_buf_len() 
14.533110 CommReceive: RecPack: (25 bytes) => bb
47 88 ad 1c 0a a0 0c 02 3b 14 10 0b 
14.533125  00 00 00 01 00 09 a1
49 5e 5e 25 fe 
16.540632 getupdateinfo: requesting 25 bytes from
ser_get_buf_len() 
16.540693 getupdateinfo: received 25 bytes from
ser_get_buf_len() 
16.540713 CommReceive: RecPack: (25 bytes) => bb
47 88 ad 1c 0b a0 54 02 01 15 10 0b 
16.540728  00 00 00 01 00 09 a1
49 5e 5e 35 fe 
18.578527 getupdateinfo: requesting 25 bytes from
ser_get_buf_len() 
18.578570 getupdateinfo: received 25 bytes from
ser_get_buf_len() 
18.578589 CommReceive: RecPack: (25 bytes) => bb
46 83 ad 19 0a a0 13 02 03 15 10 0b 
18.578604  00 00 00 01 00 09 a1
49 5e 5e ec fe 
20.586804 getupdateinfo: requesting 25 bytes from
ser_get_buf_len() 
20.586847 getupdateinfo: received 25 bytes from
ser_get_buf_len() 
20.586866 CommReceive: RecPack: (25 bytes) => bb
46 88 ad 1d 0a a0 0b 02 04 15 10 0b 
20.586881  00 00 00 01 00 09 a1
49 5e 5e ee fe 
22.628979 getupdateinfo: requesting 25 bytes from
ser_get_buf_len() 
22.629064 getupdateinfo: received 25 bytes from
ser_get_buf_len() 
22.629091 CommReceive: RecPack: (25 bytes) => bb
46 88 ad 1b 0a a0 06 02 06 15 10 0b 
22.629107  00 00 00 01 00 09 a1
49 5e 5e e9 fe 
24.634147 getupdateinfo: requesting 25 bytes from
ser_get_buf_len() 
24.634214 getupdateinfo: received 25 bytes from
ser_get_buf_len() 
24.634234 CommReceive: RecPack: (25 bytes) => bb
47 88 ad 02 0b a0 07 02 08 15 10 0b