-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2008-11-19 a las 13:30 +0100, Camaleón escribió:
Q1 => OK [(235.2 235.2 235.2 020 49.9 13.6 25.0 00001001]
El primero es el voltaje de entrada (al desenchufar se poner a cero). El 13.6 es el voltaje de la batería. 49.9 es la frecuencia de red. El 020 y el 25.0, no se, son muy estables. Si uno veo que sube será la temperatura.
La temperatura que me marca varía entre los 45-47º. La frecuencia no la veo en mis registros.
Muy alta para estar en "standby". Si estuviera activamente suministrando corriente, se entendería.
El 25.0 podría ser valores de la carga del sai.
No se, porque el mensaje completo es: Asking for UPS status [Q1]... Q1 => OK [(238.7 238.7 238.7 019 49.9 13.6 25.0 00001001] Calculated battery charge: 97.5% je, megatec_usb: The temperature value is also known to be bogus in some models.
Mi polímetro confirma esos 235 voltios. Eso explica porqué zumba el fluorescente de la cocina. Han cambiado silenciosamente el voltaje oficial de 220 a 230, por convergencia. En el reino unido eran 240, deben de bajar a 230. Toda Europa a 230.
Los voltajes menores (los 110V de EE.UU.) son más seguros ¿no? :-?
Si, en efecto, en cuanto a calambrazos; no en cuanto a incendios - IMO. Un valor bajo de voltaje implica un valor correspondientemente mayor de corriente; y el calor disipado en los cables, empalmes y enchufes es directamente proporcional a la corriente. De hecho, en USA, cuando necesitan calefacción conectan dos fases para tener 220. Yo tengo amigos en Madrid con calefacción electrica en casa (tarifa nocturna) con trifásica... no sabía que era posible (al menos en la caja tienes 380).
Si, pero resultados de pruebas posteriores niegan esa alegría... creo que falla mintiendo sobre su éxito.
Pero te estás acercando :-P
Me parece que de compilar la versión svn no me libra nadie. Esa gente lleva mucho tiempo sin liberar versión estable nueva.
Pero no puedo estudiarlo. Un broadcast es un mensaje que se imprime en absolutamente todas las consolas, bloqueando el trabajo en ellas, no puedes escribir porque se escribe encima de lo que tu escribes y no ves lo que haces. Y no veo manera de quitar esa estupidez.
Lo sé, me pasa igual con los sai, cuando estoy trabajando en la consola local y hay un corte o un pico :-)
Se puede configurar el evento (que envíe mensaje o no, y la forma de aviso), al menos algunos sai y según qué programas de gestión.
En este parece que no. Ya miraré los fuentes para quitarlo, si lo encuentro. ¿Conoces otros programas de gestión para linux? Si son los propietarios, no los quiero.
Tiene sentido un broadcast de "no tengo electricidad, voy a apagar en 5 minutos", pero no el de que no tengo comunicacion en todas las consolas. Y menos si no lo puedo anular para estudiar el problema.
Todos los eventos suelen ser configurables, pero eso depende del programa de gestión. En NUT, pues no sé si lo permitirá, supongo que sí :-?
Volveré a mirar, pero parece que este no.
No, hay un comentario que dice justo lo contrario.
¿Cuál? :-?
Yo me refería a éste:
http://lists.alioth.debian.org/pipermail/nut-upsuser/2008-February/003766.ht...
El siguiente dice: ] There indeed could be permission problems, but megatec_usb doesn't use ] hiddev nodes at all (AFAIK other USB drivers do the same). Therefore you ] don't want to change their permissions. You'd better look at udev rules ] packaged with nut (scripts/udev/). Example: Si repito su ejemplo, veo (tengo el driver corriendo en consola): nimrodel:/etc/ups # ps aux | grep megatec_usb upsd 18829 0.1 0.0 1944 916 pts/31 S+ 14:35 0:01 /usr/lib/ups/driver/megatec_usb -DDD -a myups cer 18838 0.0 0.1 3116 1872 pts/20 S+ 14:38 0:00 man megatec_usb root 19025 0.0 0.0 2116 692 pts/34 S+ 14:49 0:00 grep megatec_usb nimrodel:/etc/ups # ls -l /proc/18829/fd total 0 lrwx------ 1 root root 64 Nov 19 14:50 0 -> /dev/pts/31 lrwx------ 1 root root 64 Nov 19 14:50 1 -> /dev/pts/31 lrwx------ 1 root root 64 Nov 19 14:49 2 -> /dev/pts/31 lrwx------ 1 root root 64 Nov 19 14:50 3 -> socket:[730804] lrwx------ 1 root root 64 Nov 19 14:50 4 -> /dev/bus/usb/003/030 lrwx------ 1 root root 64 Nov 19 14:50 5 -> socket:[730866] Y fijate que no son los permiso que tiene el dispositivo: nimrodel:/etc/ups # l /dev/bus/usb/003/030 crw-rw-r-- 1 root daemon 189, 285 Nov 19 14:51 /dev/bus/usb/003/030 Y si miras el siguiente mensaje, encuentras este párrafo, que es al que me refería yo antes: ] The megatec_usb driver works (output below). The stable code didn't ] work, by the way. However, when I start upsdrvctl, it seems to start and ] says it's detected a Megatec USB UPS. However, a upsc belkin at ] localhost says Connection failure. It doesn't look like the monitor is ] starting. Así que tengo que compilar la versión de desarrollo - que puede funcionar o puede tener otro problema totalmente distinto. :-/ - -- Saludos Carlos E.R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkkkGwcACgkQtTMYHG2NR9UtXgCfVdgHuxqPmGBTId9BoS4EGgVA EawAniWkAWW1pTBidqG2r6ceObzH+6bE =ITEs -----END PGP SIGNATURE-----