[Nut-upsuser] mge-utalk ESV8+ comm problem

[Arnaud Quette]

2012/10/19 Martin Loyer <martin at martinloyer.fr>

> **
>
> Dear all,
>
>
>
>  Ivo, we really need your implication to solve *your* issue!
>
>>  I have an old ESV8 UPS down here, and I did code patching years ago to
>>>> support old model on nut.
>>>
>>> is your ESV8 still working?
>>
>>  For sure :)
>> This UPS is strong! By now, it is 18 years old :O
>
>
> made to last until the end of time ;)
> ah, good ol' MGE time.
>
>>  But, I got some bad effect, like Debian bug you mentionned on your
>>>> email.
>>>>
>>>> Would be difficult for me to gain access to an ESV8+, but we can work
>>>> together to test.
>>>
>>> even to me. all this goes back to MGE time, now defunct for 5 years.
>>> the only things that survived is the Comet and E Series DX (see below)
>>
>>  I may have access to an old ESV8+. I gave one to a friend of mine, years
>> ago.
>
>
> that would be nice
>
>>
>>  I can make some test, but I need more information. Could you send me
>>>> your
>>>> debug log?
>>>
>>> I think I've found a Comet and a E Series DX (so speaking UTalk) at
>>> Eaton today.
>>> this is the kind of things that becomes rare nowadays!
>>>
>>> on the patch side, I'd also like to:
>>> - add some more inter-char delay, since mge_command() only has 100 ms.
>>> I've just checked again Utalk spec [1], and we should be at least 500
>>> ms between commands.
>>> the point here is that this inter-char delay is not satisfied with
>>> commands that do not receive an answer (such as Z)
>>
>>  Interesting. If we are hearing too fast, it's not that good.
>
>
> we're *talking* too fast actually ;)
>
>
>  You're right ! ... I talked to fast ;)
>
>
>  For specific commands (such as Z), we may just wait and ignore any
>> answers (as we did by the past).
>
>
> not sure to get your point!? we still ignore the result of mge_command(...
> Z)
>
>  Fore sure :D
>
>
>> - see the result of Marek's mention, i.e moving the double Z before the
>>> Si test.
>>
>>  For sure. I dig on my archives, and found a serial spy log taken on
>> Windows between PSP and ESV8.
>> Z is send twice, then AX 1, then SI 1.
>
>
> yep, with 500 ms inter-commands... I still have access to that code ;)
>
>> By the way, I worked a lot to make support of programmable outlets. By
>> now, it is not supported (even for recent UPS, working on usb-hid). I may
>> test and patch.
>>
>> @Ivo: could you send me your log file?
>>
>
> @Martin: how do you want to proceed on the UTalk issue?
> I can either provide a (set of) patch(es), or few directions...
>
> Let's wait Ivo's answer and log files.
>
I don't think it's necessary.
Ivo mentioned that the situation self unblocked (maybe related to the hard
reset), and most of all that it works on Windows with Eaton SW...

my feeling is that moving the ZZ before the "Si" test, and forcing an
inter-command delay of 500 ms should do it here.
I've attached a patch. use "-p0" from the nut top source dir...

> Then, I'll try to fix it. Then we test it, and validate on severals UPS.
> If OK, I'let you publish patch Arnaud.
>
> If I have some time, I can work on programmable outlet, with limited
> support to onboard one (no external outlet plugged in daisy chain).
>
could be nice.
it would also be a good time to it now, since Ivo may also test it on his
units.
I'll check on my side if I can bootstrap a base code...

cheers,
Arnaud
-- 
Network UPS Tools (NUT) Project Leader - http://www.networkupstools.org
Debian Developer - http://www.debian.org
Free Software Developer - http://arnaud.quette.fr
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20121019/71080bc3/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: utalk-zz500ms.diff
Type: application/octet-stream
Size: 1186 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20121019/71080bc3/attachment.obj>