Mate3Parser sched_x_ac_mode - disabled mode can not be set about mate3 HOT 14 CLOSED

I'm not 100% sure what you're asking, but you could try #6 and see if there's any difference - I've significantly changed how this all works. (It is incomplete though, and as yet doesn't support writes.) I've just tested on mine and "sched_1_ac_mode" is apparently not implemented by the mate modbus (i.e. it's returning 0xFFFF as per below - which matches your comment "Disabled # -1 in fact is (65535)"):

Don't trust my code at this stage, but if that is the case, it's an Outback issue for not providing full modbus support.

from mate3.

i set by purpose in Mate both Generator and Disabled:
sched_1_ac_mode = Generator
sched_2_ac_mode = Backup
sched_3_ac_mode = Disabled
take a look in attached, sched_3_ac_mode is reported as zero instead of 65535.
Hope that i was clear.

mate3allblocks.txt

from mate3.

See here:

from mate3.

actually I'm using a modified code that skip def decode_int16(signed_value) - so the code is giving me the original value (65535)
I'm waiting with to see the final version after all updates / changes performed by you before any other actions from my side.
thanks for response

from mate3.

I'm waiting with to see the final version after all updates / changes performed by you before any other actions from my side

#6 is merged and you can just pip install -U mate3 to get it - let me know if it works!

from mate3.

There is a conflict in reading "Disabled" and "Generator" ac_mode - both are reported with 0

@chinezbrun It looks like this is fixed in the big 0.5.* PR, as using the dump you sent me, I get this:

Mate3DeviceValues

Can you test if writing works (the other part of your issue)? Thanks

from mate3.

sure, happy to test but i need to be sure about the syntax.
before to client.write() is like:

mate = client.devices.mate3
mate.sched_1_ac_mode.value = xx

if yes, how xx should look like ?
confused because on read the sched_1_ac_mode.value return sched_1_ac_mode.Mini Grid: 5

from mate3.

Similar to the example, you just use the enum value you want. If you check out the field definition you probably want the below:

mate.sched_1_ac_mode.value = OutBackModel.sched_1_ac_mode.options['Disable']

from mate3.

Wow.
tested and still not ok
python:

from loguru import logger
import sys
import time
from mate3.api import Mate3Client

logger.remove()
logger.add(sys.stderr, level="DEBUG")

with Mate3Client("192.168.0.150") as client:
    client.read()
    mate = client.devices.mate3
    print("actual value :" , mate.sched_1_ac_mode.value)
    new_value = mate.sched_1_ac_mode.field.options['Disable']
    mate.sched_1_ac_mode.value = new_value
    print ("new value :" , mate.sched_1_ac_mode.value)
    client.write()

output here
error_sch_mode.txt

based on my experience the value should be 65535 instead of -1 for successful writing

from mate3.

Hmmm, that's interesting. Looks like a twos-complement thing - I'll look into it soon.

from mate3.

Oops, sorry @chinezbrun - looks like github automatically closed this as I said "Fixes #9" in #19. But I've reopened since you haven't had a chance to verify.

With that in mind, can you try 0.5.3 and see if it works? It should now be writing 65535. Let me know how it goes.

from mate3.

yes. it works. the disabled, generator are written correct now.
see below the output.
testwritting_output.txt

btw... do you know why in the python code above, the new_value is not printed correct? based on the output new_value is loaded as is written correct on the Mate ...

from mate3.

Nifty.

If I'm understanding correctly, you're wondering why print ("new value :" , mate.sched_1_ac_mode.value) still prints the old value? This is because the value doesn't get updated until after you've called client.write(). You can see this in the example in the main readme, where the field is marked as Dirty with a new value, etc. You'll see this if you change to print ("new value :" , mate.sched_1_ac_mode). This did just make me think of something that could be improved, so I'll add that to a new issue.

from mate3.

yes that's it. thanks for explanation. clear.
This mark, "Dirty is a good one if you can use it / exploit in future codes somehow :)

from mate3.