Use the Set Serial API (0x0B) to reset nodeId to 8 bits

[apella12]

The other PR was not going to work without major refactoring to allow both 8 and 16 bit node IDs. Since the binding can not support LR nodes anyway (S2 and Smart Start are also required), this PR sends a message to use 8bit. It worked on a zooz 800 with SDK 7.22 originally using 16bit. (I used Simplicity studio to change the zooz 700 controller on 7.21.41.

Signed-off-by: Bob Eckhoff [email protected]

[apella12]

Don't know if you are busy or waiting on more information. In case of the latter here is a sample of the debug files;

1. New OOB Zooz 800 with current binding
   openhab800new.log
   
2. Binding with PR (includes device exclusion and inclusion after controller initialization)
   (openhab800withfix.txt)
   
3. Binding with PR on 500 controller (Suspected the CC 0x0b was not supported- it isn't, but doesn't seem to cause problems). I did add the OR based on the device response however)
   openhab500withfix.txt

[cdjackson]

Sorry - I missed that you'd removed the draft tag. I'll try and take a look later today.

[cdjackson]

Thanks.

Two points. Firstly, does this work on old controllers or will it (possibly) cause a problem? I'm just wondering if we shouldn't make this conditional and only send it on 800 controllers?

Second point - can you pull out the constants and put them at the top of the file as static int rather than using them directly. I appreciate it's a short file, but it's generally better to keep constant defs at the top.

[apella12]

Firstly, does this work on old controllers

The third Debug above was a run on my original (several years ago) Aeotec 5. The firmware had been upgraded FW 6.07, but the Library was 1.

2025-01-07 14:30:50.221 [DEBUG] [serialmessage.GetVersionMessageClass] - Got MessageGetVersion response. Version=Z-Wave 6.07, Library Type=1
2025-01-07 14:30:50.222 [DEBUG] [e.internal.protocol.ZWaveTransaction] - TID 0: Transaction COMPLETED
snip
2025-01-07 14:30:50.225 [DEBUG] [ing.zwave.handler.ZWaveSerialHandler] - NODE 255: Sending REQUEST Message = 01 05 00 0B 80 01 70 
2025-01-07 14:30:50.226 [DEBUG] [ing.zwave.handler.ZWaveSerialHandler] - Message SENT
2025-01-07 14:30:50.226 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage started: TID 1: [WAIT_RESPONSE] priority=Controller, requiresResponse=true, callback: 0
2025-01-07 14:30:50.226 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 06
2025-01-07 14:30:50.227 [DEBUG] [nal.protocol.ZWaveTransactionManager] - processReceiveMessage input 0<>128 : Message: class=null[0], type=ACK[2], dest=255, callback=0, payload=
2025-01-07 14:30:50.227 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Received msg (0): Message: class=null[0], type=ACK[2], dest=255, callback=0, payload=
2025-01-07 14:30:50.227 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 05 01 0B 00 80 70 
2025-01-07 14:30:50.227 [DEBUG] [nal.protocol.ZWaveTransactionManager] - lastTransaction TID 1: [WAIT_RESPONSE] priority=Controller, requiresResponse=true, callback: 0
2025-01-07 14:30:50.227 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Received msg: ACK
2025-01-07 14:30:50.227 [DEBUG] [nal.protocol.ZWaveTransactionManager] - ZWaveReceiveThread queue empty
2025-01-07 14:30:50.227 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage 1 out at start. Holdoff false.
2025-01-07 14:30:50.228 [DEBUG] [nal.protocol.ZWaveTransactionManager] - processReceiveMessage input 0<>128 : Message: class=SetUpZwaveApi[11], type=Response[1], dest=255, callback=0, payload=00 80 
2025-01-07 14:30:50.228 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Received msg (0): Message: class=SetUpZwaveApi[11], type=Response[1], dest=255, callback=0, payload=00 80 
2025-01-07 14:30:50.229 [DEBUG] [nal.protocol.ZWaveTransactionManager] - lastTransaction TID 1: [WAIT_RESPONSE] priority=Controller, requiresResponse=true, callback: 0
2025-01-07 14:30:50.230 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Checking outstanding transactions: 1
2025-01-07 14:30:50.230 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Last transaction: TID 1: [WAIT_RESPONSE] priority=Controller, requiresResponse=true, callback: 0
2025-01-07 14:30:50.230 [DEBUG] [ve.internal.protocol.ZWaveController] - Incoming Message: Message: class=SetUpZwaveApi[11], type=Response[1], dest=255, callback=0, payload=00 80 
2025-01-07 14:30:50.231 [DEBUG] [ialmessage.SetNodeIdTypeMessageClass] - SetNodeIdType node response
2025-01-07 14:30:50.231 [DEBUG] [ialmessage.SetNodeIdTypeMessageClass] - Eight bit NodeId command OK.
2025-01-07 14:30:50.231 [DEBUG] [nal.protocol.ZWaveTransactionManager] - TID 1: Advanced to DONE

My conclusion from the response was that serial command 0x0B was not in that library so no harm no foul. The device returned 00 80, so I adjusted the condition for the debug statement to be positive, since 8-bit NodeId is the only option for Library <7. I did look at putting the Library 7 condition and ran into "making a static reference to dynamic method java error". The AI suggested creating a new local version of the Version class, but wasn't sure it would pick up that property since it was just identified from the previous command. Decided to do what I did. EDIT also had concerns if I bypassed the message in Command class what would happen (would it just go to the next command)

    public void initialize() {
        enqueue(new GetVersionMessageClass().doRequest());  /returns the Library (1 or 7 or ?)
        enqueue(new SetNodeIdTypeMessageClass().doRequest()); //not known if this needed or not at this point
        enqueue(new MemoryGetIdMessageClass().doRequest());  // this request must know the 8-bit or 16-bit answer
        enqueue(new SerialApiGetCapabilitiesMessageClass().doRequest());
        enqueue(new SerialApiSetTimeoutsMessageClass().doRequest(150, 15));
        enqueue(new GetSucNodeIdMessageClass().doRequest());

can you pull out the constants

Are you referencing these constants?

        payload[0] = (byte) 0x80;
        payload[1] = (byte) 0x01;  // 1=8 bit, 2=16 bit

to something like this;

    private static byte payload0 = (byte) 0x80; // Subclass of SetUpZwaveAPI for NodeID Type
    private static byte payload1 = (byte) 0x01;  // 1=8 bit, 2=16 bit NodeID Type

[cdjackson]

Thanks.

Yes, those are the constants I meant. Instead of calling them payload0 etc I'd give them a meaningful name - so maybe CMD_SETNODEID for pl0 and NODEID_8BIT for the pl1?