similar to: New nutdrv_qx sub driver - protocol v15&16

Hi and thank you for your effort. You are very close to what I want to achieve, but I was already aware of the impossibility of querying direct from a command. I wanted the following (both would be covered by your changes): 1. preprocess an item_t in the direction: NUT->DEVICE in order to be able to support queries like ups.generated.yesterday

Hi Thank you very much for the feedback. I will download and try to get it working on the Raspberry Pi. Regards Tom On Sun, Feb 14, 2016 at 1:49 AM, hyouko at gmail.com <hyouko at gmail.com> wrote: > > I have the RCT 3KVA Axpert solar hybrid inverter. It is also known as > the > > MPP Solar PIP-MS series, the IPS-4000WM and the Voltronic Axpert MKS. I > am > >

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I would like to propose an interface change/extension, in order to be able to clearly differ from a PRE_SEND and a POST_RECEIVE item_t->preprocess-ing calls. IMHO there is no option to differ from item->preprocess(..), called from [1] and called from [2], at the moment. My idea is to extend the item_t->preprocess(..) with an additional

> I have the RCT 3KVA Axpert solar hybrid inverter. It is also known as the > MPP Solar PIP-MS series, the IPS-4000WM and the Voltronic Axpert MKS. I am This device could be supported by nutdrv_qx (subdriver 'voltronic-sunny') built starting from this branch: https://github.com/zykh/nut/tree/nutdrv_qx_voltronic-sunny_rebased+command Please note that this subdriver is not ready

mmh.. At the moment there are 3 distinct preprocess functions that operate on 2 different types: - info_rw_t - preprocess(); - item_t - preprocess(); - item_t - preprocess_answer(). For info_rw_t: range/enum values are preprocessed just to see if that specific value is to be used or not depending on the conditions the driver meets at runtime (e.g.: low voltage devices -> low voltage ranges).

Hi I have the RCT 3KVA Axpert solar hybrid inverter. It is also known as the MPP Solar PIP-MS series, the IPS-4000WM and the Voltronic Axpert MKS. I am trying to monitor the inverter using NUT on a Raspberry Pi (I have tried Ubuntu as well with the same results). I have tried most of the drivers with no success. The inverter came with the ViewPower software so I assumed that my best chance

Yet again, sorry for the delay - I hope the UPS is still alive. >> I noticed that your UPS seems to support the 'M' command as a query of >> some sort (it replies '0'): now I'm curious as to what it does mean. >> >> It could be the 0-9 index of the user-settable voltage limits, page 19 of: >>

On Apr 4, 2015, at 7:19 PM, Richard Flint <richard.flint at gmail.com> wrote: > More extensive debugging by running the driver sudo ./nutdrv_qx -u root -a MY_UPS -DDDDDD indicates the driver works normally then will randomly stop working at stop "send: QS". The debug logs show values successfully retrieved repeatedly until something like: > .... > Quick update... >

> Sure enough, it turned off after about 30 seconds (t=228). I unplugged it for about five seconds, and it came back on three minutes after I plugged it back in. However, the bypass bit inversion might be responsible for this: > > 228.304623 send: 'Q1' > 228.515426 read: '(119.0 119.0 000.0 000 60.0 13.5 XX.X 00001010' > 228.515494 ups_infoval_set: non

On Nov 7, 2014, at 5:31 PM, hyouko at gmail.com wrote: >> Sure enough, it turned off after about 30 seconds (t=228). I unplugged it for about five seconds, and it came back on three minutes after I plugged it back in. However, the bypass bit inversion might be responsible for this: >> >> 228.304623 send: 'Q1' >> 228.515426 read: '(119.0 119.0 000.0 000

On 16/03/15 13:16, Peter Zijlstra wrote: > > I feel that if someone were to do a Xen patch we can go ahead and merge this > stuff (finally!). This seems work for me, but I've not got time to give it a more thorough testing. You can fold this into your series. There doesn't seem to be a way to disable QUEUE_SPINLOCKS when supported by the arch, is this intentional? If so, the

On Mon, Mar 16, 2015 at 02:16:13PM +0100, Peter Zijlstra wrote: > Hi Waiman, > > As promised; here is the paravirt stuff I did during the trip to BOS last week. > > All the !paravirt patches are more or less the same as before (the only real > change is the copyright lines in the first patch). > > The paravirt stuff is 'simple' and KVM only -- the Xen code was a

On Thu, Mar 26, 2015 at 09:21:53PM +0100, Peter Zijlstra wrote: > On Wed, Mar 25, 2015 at 03:47:39PM -0400, Konrad Rzeszutek Wilk wrote: > > Ah nice. That could be spun out as a seperate patch to optimize the existing > > ticket locks I presume. > > Yes I suppose we can do something similar for the ticket and patch in > the right increment. We'd need to restructure the

On Mon, Mar 30, 2015 at 12:25:12PM -0400, Waiman Long wrote: > I did it differently in my PV portion of the qspinlock patch. Instead of > just waking up the CPU, the new lock holder will check if the new queue head > has been halted. If so, it will set the slowpath flag for the halted queue > head in the lock so as to wake it up at unlock time. This should eliminate > your concern

On 16/03/15 13:16, Peter Zijlstra wrote: > > I feel that if someone were to do a Xen patch we can go ahead and merge this > stuff (finally!). This seems work for me, but I've not got time to give it a more thorough testing. You can fold this into your series. There doesn't seem to be a way to disable QUEUE_SPINLOCKS when supported by the arch, is this intentional? If so, the

On Mon, Mar 16, 2015 at 02:16:13PM +0100, Peter Zijlstra wrote: > Hi Waiman, > > As promised; here is the paravirt stuff I did during the trip to BOS last week. > > All the !paravirt patches are more or less the same as before (the only real > change is the copyright lines in the first patch). > > The paravirt stuff is 'simple' and KVM only -- the Xen code was a

On Thu, Mar 26, 2015 at 09:21:53PM +0100, Peter Zijlstra wrote: > On Wed, Mar 25, 2015 at 03:47:39PM -0400, Konrad Rzeszutek Wilk wrote: > > Ah nice. That could be spun out as a seperate patch to optimize the existing > > ticket locks I presume. > > Yes I suppose we can do something similar for the ticket and patch in > the right increment. We'd need to restructure the

On Mon, Mar 30, 2015 at 12:25:12PM -0400, Waiman Long wrote: > I did it differently in my PV portion of the qspinlock patch. Instead of > just waking up the CPU, the new lock holder will check if the new queue head > has been halted. If so, it will set the slowpath flag for the halted queue > head in the lock so as to wake it up at unlock time. This should eliminate > your concern

On 07/04/15 03:55, Waiman Long wrote: > This patch adds the necessary Xen specific code to allow Xen to > support the CPU halting and kicking operations needed by the queue > spinlock PV code. This basically looks the same as the version I wrote, except I think you broke it. > +static void xen_qlock_wait(u8 *byte, u8 val) > +{ > + int irq = __this_cpu_read(lock_kicker_irq);

On Wed, Apr 08, 2015 at 02:32:19PM -0400, Waiman Long wrote: > For a virtual guest with the qspinlock patch, a simple unfair byte lock > will be used if PV spinlock is not configured in or the hypervisor > isn't either KVM or Xen. The byte lock works fine with small guest > of just a few vCPUs. On a much larger guest, however, byte lock can > have serious performance problem.