Matthew, I've looked briefly at the files you uploaded to GitHub and it seems to me that the device is like something that should work with the 'fabula' USB subdriver (and 'megatec' protocol): what are the issues you are experiencing and that prevent the driver to work?
Hi, it does communicate using the fabula subdriver but I don't get any of the values parsed. If I execute: ./nutdrv_qx -a powercool -DDDDD -x subdriver=fabula -x vendorid=0001 -x productid=0000 I get the following returned: 12.242991 upsdrv_updateinfo... 12.243047 Quick update... 12.243069 send: Q1 12.243087 command index: 0x03 12.249983 read: (47 bytes) => 28 30 30 30 2e 30 20 30 30 30 2e 30 20 30 30 30 2e 30 12.250037 20 30 30 30 20 30 30 2e 30 20 30 2e 30 30 20 30 30 2e 30 20 30 30 30 30 30 12.250055 30 30 30 0d 12.250069 read: (000.0 000.0 000.0 000 00.0 0.00 00.0 00000000 12.250091 update_status: OL 12.250112 update_status: !LB 12.250136 update_status: !CAL 12.250158 update_status: !FSD On 2 October 2016 at 23:26, hyouko at gmail.com <hyouko at gmail.com> wrote:> Matthew, I've looked briefly at the files you uploaded to GitHub and > it seems to me that the device is like something that should work with > the 'fabula' USB subdriver (and 'megatec' protocol): what are the > issues you are experiencing and that prevent the driver to work? >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.alioth.debian.org/pipermail/nut-upsdev/attachments/20161003/71f5b762/attachment.html>
> 12.243069 send: Q1 > 12.243087 command index: 0x03 > 12.249983 read: (47 bytes) => 28 30 30 30 2e 30 20 30 30 30 2e 30 20 30 30 > 30 2e 30 > 12.250037 20 30 30 30 20 30 30 2e 30 20 30 2e 30 30 20 30 30 2e 30 20 30 > 30 30 30 30 > 12.250055 30 30 30 0d > 12.250069 read: (000.0 000.0 000.0 000 00.0 0.00 00.0 00000000Uh, a bit unexpected, but, at least, we got the right reply for that query. I'll have to look again at the logs you posted on GitHub in order to see if there is any difference with what the driver does now. Meanwhile, can you post the complete log of the startup of the driver (like the one you just posted, but not trimmed, and then let the driver run for a couple of minutes)?
> On Oct 10, 2016, at 4:29 PM, Matthew Wire <mjw at mjwconsult.co.uk> wrote: > > Here is the complete log for two minutes from startup. thank youcompressed to fit on the mailing list.> > On 9 October 2016 at 23:41, hyouko at gmail.com <hyouko at gmail.com> wrote: > > 12.243069 send: Q1 > > 12.243087 command index: 0x03 > > 12.249983 read: (47 bytes) => 28 30 30 30 2e 30 20 30 30 30 2e 30 20 30 30 > > 30 2e 30 > > 12.250037 20 30 30 30 20 30 30 2e 30 20 30 2e 30 30 20 30 30 2e 30 20 30 > > 30 30 30 30 > > 12.250055 30 30 30 0d > > 12.250069 read: (000.0 000.0 000.0 000 00.0 0.00 00.0 00000000 > > Uh, a bit unexpected, but, at least, we got the right reply for that query. > I'll have to look again at the logs you posted on GitHub in order to > see if there is any difference with what the driver does now. > Meanwhile, can you post the complete log of the startup of the driver > (like the one you just posted, but not trimmed, and then let the > driver run for a couple of minutes)? > > <powercool.log>-------------- next part -------------- A non-text attachment was scrubbed... Name: powercool.log.gz Type: application/x-gzip Size: 6570 bytes Desc: not available URL: <http://lists.alioth.debian.org/pipermail/nut-upsdev/attachments/20161010/47c51755/attachment.bin>
Thanks for the log - apparently we always get valid (apart from 0.191312) but empty replies, not only for index 0x03, but also for the other queried index (0x0c). I've re-looked at the logs you posted on GitHub, but I don't see anything exotic going on there. Maybe we're missing some sort of handshaking or the like: can you post the whole captures/logs, right from when you plug the cable till the communication is established with UPSmart1.5?