Since we get valid replies (when we get any), I'm assuming we're speaking the right 'dialect' and using the right (or an almost right) serial-over-USB implementation. Apparently, after a successful query, it takes the device ~10 seconds to reply (see how, when trying to read the reply to the 'QS' query at ~23s, we actually get the reply -the one starting with a '#'- to the 'F' query sent at ~13s, and when trying to read the reply to the latter, we actually get the reply to a 'QS' query, probably the one sent at ~3s). If that's really the case, I'm not sure there's much we can do... you could try to ease the pace of the polling to match the time the device needs to reply, so that every new poll will get the reply to the last one (e.g. setting 'pollinterval', or 'i' arg, to 10 seconds or something like that). Also, you could try another serial-over-USB subdriver (namely the 'phoenix' one, instead of the default 'cypress' one, but feel free to try also the other ones). Finally, if you end up with a usable setup and if the device still needs 10s to answer our queries, consider using the 'norating' and 'novendor' flags, since it's not likely that we get any reply to those queries in time to process them (and then they could even be seen as 'pollution' to the next status queries).
_______________________________________________ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
