Announcement

Collapse
No announcement yet.

2413S: X10 "Preset Dim" commands are sent incorrectly

Collapse
This topic is closed.
X
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    2413S: X10 "Preset Dim" commands are sent incorrectly

    Hi,

    SUMMARY:

    Using a Smarthome 2413S with HomeSeer 2.5.0.4 and Insteon Plugin 1.5.2.0 OR 1.4.2.0, I can't get HomeSeer to send X10 Preset Dim commands correctly.

    - HS Version: 2.5.0.4
    - Insteon Plugin Version: 1.5.2.0 or 1.4.2.0
    - Error occurred: X10 Preset Dim Commands don't work correctly
    - Reproducible: Yes

    There's a lot of detailed technical info below, getting into the bits and bytes of the PLM message protocol. Casual readers may want to skip, but hopefully, this detail will prove to be sufficient for the programmers to figure out what's going wrong. Thanks in advance for any help you can provide!

    DETAILS:

    I have a mostly X10 system. It is almost all SmartHome SwitchLinc X10 device based, with extensive scene programming in the various devices.

    Long story short: I've ended up with the SmartHome 2413S, because my 1132 CU died, and then my 2414U died. Additionally many of my SwitchLincs have begun to die, and I wanted a path to Insteon, so the 2413S seemed like a good selection. (Side note: what is up with all of these SmartHome devices failing?!! Do other people see this as well?)

    I'm using the 2413S with the free 1.4.2.0 plugin. HomeSeer can successfully send X10 On and Off commands to trigger various scenes, but I've found that I can't send "Preset Dim" commands from HomeSeer to the X10-based Switchlincs correctly. If I try to send any dim value between 50 and 100% (16 to 31), Homeseer instead sends a Preset Dim to 0% and the light turns off. If I try to send any dim value between 0 and 48% (0 to 15), Homeseer instead sends a Preset Dim to 51.6% and the light turns on to about half brightness.

    I updated HomeSeer from 2.4.0.11 to 2.5.0.4. That didn't help. And I tried installing the new Insteon Plugin 1.5.2. That didn't help either. I've reverted back to 1.4.2.0

    So I decided to look at the actual bytes being sent to the PLM controller to see if it was HomeSeer/Plugin/Computer screwing up, or if it was the PLM screwing up. Answer: it is HomeSeer/Plugin/Computer that is screwing up. They are sending the wrong command data to the PLM.

    Here's a couple of pieces of the log file with comments

    This first log snippet shows what happens when I use the Homeseer Status window to set the dim level of device C1 to 40%. The results are the same for the 1.4.0.11 and the 1.5.2.0 Insteon PLM plugins

    12/25/2010 4:44:30 PM ~!~Insteon~!~Queueing X10 Command: C1 Cmd: 10 Pcnt: 12 Data1: 0 Data2: 0
    12/25/2010 4:44:30 PM ~!~Insteon~!~Preset DIM level 12
    12/25/2010 4:44:30 PM ~!~Device Control~!~Device: Brooks OfficeBrooks Office Light Preset Dim Level 12 [40%]
    12/25/2010 4:44:30 PM ~!~Insteon~!~Sending command 02 63 26 00 to RF PLM, (Expecting 0 bytes extra back) Pre-Payload ACK:False, NAK is ok:False
    12/25/2010 4:44:30 PM ~!~Insteon~!~..Got RF PLM Response 02 63 26 00 06
    12/25/2010 4:44:30 PM ~!~Insteon~!~Sending command 02 63 0B 80 to RF PLM, (Expecting 0 bytes extra back) Pre-Payload ACK:False, NAK is ok:False
    12/25/2010 4:44:31 PM ~!~Insteon~!~..Got NAK from the RF PLM for command
    12/25/2010 4:44:31 PM ~!~Insteon~!~..Retry #1 required. Pausing 250ms for RF PLM to clear...
    12/25/2010 4:44:31 PM ~!~Insteon~!~..Got RF PLM Response 02 63 0B 80 06


    As you can see, the third byte in the last command is 0x0B, which represents a preset dim value of about 51% (half bright). The same 0x0B value is sent for ANY dim level requested via Homeseer between 0% and 48% (0-15)

    The correct third byte for the dim level of 40% (12) should have been 0x3D instead of 0x0B. Here is the correct transmit sequence:
    02 63 3D 80

    This next log snippet shows what happens when I use the Homeseer Status window to set the dim level of device C1 to 90%. The results are the same for the 1.4.0.11 and the 1.5.2.0 Insteon PLM plugins

    12/25/2010 4:47:22 PM ~!~Insteon~!~Queueing X10 Command: C1 Cmd: 10 Pcnt: 28 Data1: 0 Data2: 0
    12/25/2010 4:47:22 PM ~!~Device Control~!~Device: Brooks OfficeBrooks Office Light Preset Dim Level 28 [90%]
    12/25/2010 4:47:22 PM ~!~Insteon~!~Preset DIM level 28
    12/25/2010 4:47:22 PM ~!~Insteon~!~Sending command 02 63 26 00 to RF PLM, (Expecting 0 bytes extra back) Pre-Payload ACK:False, NAK is ok:False
    12/25/2010 4:47:22 PM ~!~Insteon~!~..Got RF PLM Response 02 63 26 00 06
    12/25/2010 4:47:22 PM ~!~Insteon~!~Sending command 02 63 0A 80 to RF PLM, (Expecting 0 bytes extra back) Pre-Payload ACK:False, NAK is ok:False
    12/25/2010 4:47:23 PM ~!~Insteon~!~..Got NAK from the RF PLM for command
    12/25/2010 4:47:23 PM ~!~Insteon~!~..Retry #1 required. Pausing 250ms for RF PLM to clear...
    12/25/2010 4:47:23 PM ~!~Insteon~!~..Got RF PLM Response 02 63 0A 80 06


    As you can see, the third byte in the last command is 0x0A, which represents a preset dim value of 0%. In other words, the light turns off. The same 0x0A value is sent for ANY dim level requested via HomeSeer between 52 and 100% (16-31)

    The correct third byte for the dim level of 90% (28) should have been 0x3B instead of 0x0A. Here is the correct transmit sequence that should have been sent:
    02 63 3B 80


    Also note that there appears to be another bug. Each sequence above indicates a NAK from the RF PLM. I looked at the data stream from the PLM using a Serial Port monitor program, and HomeSeer (or the Insteon Plugin) is inadvertantly sending two extra Start of Message bytes between the House/Unit transmission and the Preset Dim transmission. These both cause a NAK (0x15) from the PLM. Here is the sequence sent & Received when using Homeseer to request a preset dim level of 40% for C1:

    Sent: 02 63 26 00 HCUC: C1
    Rcvd: 02 63 26 00 06 Response with acknowledgement
    Sent: 02 SOM
    Sent: 02 Second SOM (error)
    Rcvd: 15 NAK acknowledging the error. Second SOM value is not allowed
    Rcvd: 15 Another NAK. I'm not sure if this occurs here or after sending the next message
    Sent: 02 63 0A 80 Preset Dim message indicating to go to 51% (16) brightness. Should be 40% (12)
    Rcvd: 02 63 0A 80 06 Response with Acknowledgement


    So, I don't know if the problem is with HomeSeer or with the Insteon PLM plugin. But I do know I never had this problem when using other controllers, including the 1132CU and the 2414U. Its only with the 2413S.

    Any help is appreciated. And I'm willing to buy the 1.5.2 plugin if it can be fixed to resolve this problem.

    Stripped down Insteon Error Report Log is shown below (Forum says I'm not allowed to post an attachment, or I would have done that).

    INSTEON ERROR REPORT --------------------------------------

    12/25/2010 6:18:28 PM - Queueing X10 Command: C1 Cmd: 10 Pcnt: 0 Data1: 0 Data2: 0
    12/25/2010 6:18:28 PM - Preset DIM level 0
    12/25/2010 6:18:28 PM - ResourceMananger::RequestExclusive for Resource 1
    12/25/2010 6:18:28 PM - Sending command 02 63 26 00 to PLM, (Expecting 0 bytes extra back) Pre-Payload ACK:False, NAK is ok:False
    12/25/2010 6:18:28 PM - ResourceMananger::ReleaseExclusive for Resource 1
    12/25/2010 6:18:28 PM - ResourceMananger::RequestExclusive for Resource 1
    12/25/2010 6:18:28 PM - Sending command 02 63 0B 80 to PLM, (Expecting 0 bytes extra back) Pre-Payload ACK:False, NAK is ok:False
    12/25/2010 6:18:28 PM - ..PLM NAKed our STX, retrying without penalty...
    12/25/2010 6:18:28 PM - ..Retry required. Pausing 250ms for PLM to clear...
    12/25/2010 6:18:29 PM - Sending command 02 63 0B 80 to PLM, (Expecting 0 bytes extra back) Pre-Payload ACK:False, NAK is ok:False
    12/25/2010 6:18:29 PM - ..PLM NAKed our STX, retrying without penalty...
    12/25/2010 6:18:29 PM - ..Retry required. Pausing 250ms for PLM to clear...
    12/25/2010 6:18:29 PM - Sending command 02 63 0B 80 to PLM, (Expecting 0 bytes extra back) Pre-Payload ACK:False, NAK is ok:False
    12/25/2010 6:18:29 PM - ResourceMananger::ReleaseExclusive for Resource 1
    12/25/2010 6:18:39 PM - Queueing X10 Command: C1 Cmd: 10 Pcnt: 3 Data1: 0 Data2: 0
    12/25/2010 6:18:39 PM - Preset DIM level 3
    12/25/2010 6:18:39 PM - ResourceMananger::RequestExclusive for Resource 1
    12/25/2010 6:18:39 PM - Sending command 02 63 26 00 to PLM, (Expecting 0 bytes extra back) Pre-Payload ACK:False, NAK is ok:False
    12/25/2010 6:18:39 PM - ResourceMananger::ReleaseExclusive for Resource 1
    12/25/2010 6:18:39 PM - ResourceMananger::RequestExclusive for Resource 1
    12/25/2010 6:18:39 PM - Sending command 02 63 0B 80 to PLM, (Expecting 0 bytes extra back) Pre-Payload ACK:False, NAK is ok:False
    12/25/2010 6:18:39 PM - ..PLM NAKed our STX, retrying without penalty...
    12/25/2010 6:18:39 PM - ..Retry required. Pausing 250ms for PLM to clear...
    12/25/2010 6:18:39 PM - Sending command 02 63 0B 80 to PLM, (Expecting 0 bytes extra back) Pre-Payload ACK:False, NAK is ok:False
    12/25/2010 6:18:39 PM - ..PLM NAKed our STX, retrying without penalty...
    12/25/2010 6:18:39 PM - ..Retry required. Pausing 250ms for PLM to clear...
    12/25/2010 6:18:39 PM - Sending command 02 63 0B 80 to PLM, (Expecting 0 bytes extra back) Pre-Payload ACK:False, NAK is ok:False
    12/25/2010 6:18:39 PM - ResourceMananger::ReleaseExclusive for Resource 1
    12/25/2010 6:18:45 PM - Queueing X10 Command: C1 Cmd: 10 Pcnt: 31 Data1: 0 Data2: 0
    12/25/2010 6:18:45 PM - Preset DIM level 31
    12/25/2010 6:18:45 PM - ResourceMananger::RequestExclusive for Resource 1
    12/25/2010 6:18:45 PM - Sending command 02 63 26 00 to PLM, (Expecting 0 bytes extra back) Pre-Payload ACK:False, NAK is ok:False
    12/25/2010 6:18:45 PM - ResourceMananger::ReleaseExclusive for Resource 1
    12/25/2010 6:18:45 PM - ResourceMananger::RequestExclusive for Resource 1
    12/25/2010 6:18:45 PM - Sending command 02 63 0A 80 to PLM, (Expecting 0 bytes extra back) Pre-Payload ACK:False, NAK is ok:False
    12/25/2010 6:18:45 PM - ..PLM NAKed our STX, retrying without penalty...
    12/25/2010 6:18:45 PM - ..Retry required. Pausing 250ms for PLM to clear...
    12/25/2010 6:18:45 PM - Sending command 02 63 0A 80 to PLM, (Expecting 0 bytes extra back) Pre-Payload ACK:False, NAK is ok:False
    12/25/2010 6:18:46 PM - ..PLM NAKed our STX, retrying without penalty...
    12/25/2010 6:18:46 PM - ..Retry required. Pausing 250ms for PLM to clear...
    12/25/2010 6:18:46 PM - Sending command 02 63 0A 80 to PLM, (Expecting 0 bytes extra back) Pre-Payload ACK:False, NAK is ok:False
    12/25/2010 6:18:46 PM - ResourceMananger::ReleaseExclusive for Resource 1
    12/25/2010 6:19:00 PM - Queueing X10 Command: C1 Cmd: 10 Pcnt: 9 Data1: 0 Data2: 0
    12/25/2010 6:19:00 PM - Preset DIM level 9
    12/25/2010 6:19:00 PM - ResourceMananger::RequestExclusive for Resource 1
    12/25/2010 6:19:00 PM - Sending command 02 63 26 00 to PLM, (Expecting 0 bytes extra back) Pre-Payload ACK:False, NAK is ok:False
    12/25/2010 6:19:00 PM - ResourceMananger::ReleaseExclusive for Resource 1
    12/25/2010 6:19:00 PM - ResourceMananger::RequestExclusive for Resource 1
    12/25/2010 6:19:00 PM - Sending command 02 63 0B 80 to PLM, (Expecting 0 bytes extra back) Pre-Payload ACK:False, NAK is ok:False
    12/25/2010 6:19:00 PM - ..PLM NAKed our STX, retrying without penalty...
    12/25/2010 6:19:00 PM - ..Retry required. Pausing 250ms for PLM to clear...
    12/25/2010 6:19:01 PM - Sending command 02 63 0B 80 to PLM, (Expecting 0 bytes extra back) Pre-Payload ACK:False, NAK is ok:False
    12/25/2010 6:19:01 PM - ..PLM NAKed our STX, retrying without penalty...
    12/25/2010 6:19:01 PM - ..Retry required. Pausing 250ms for PLM to clear...
    12/25/2010 6:19:01 PM - Sending command 02 63 0B 80 to PLM, (Expecting 0 bytes extra back) Pre-Payload ACK:False, NAK is ok:False
    12/25/2010 6:19:01 PM - ResourceMananger::ReleaseExclusive for Resource 1
    12/25/2010 6:46:36 PM - ***:Forced error / log generation
    --------*End Pre-Error Log*--------------
    --------*Start C:\Program Files\HomeSeer HS2\Config\Insteon.ini*--------------
    [Config]
    MaxHops=2
    NumRetries=5
    WaitTimeout=3
    DetailedLog=3
    DoCleanups=1
    GroupBaseCode=[
    LastInterfaceAddress=13.21.82
    DeviceLocationFilterIndex=0
    NumDevices=1
    DeviceBaseCode=[
    UseLocation2=0
    DisablePolling=0
    [Device 1]
    DeviceID=00.75.82
    DeviceName=Tap-Added ControLinc V2 0
    DeviceLocation=Unknown
    PollingInterval=0
    DeviceType=0004
    FirmwareVer=22
    DatabaseDelta=-1
    LinksDownloaded=0
    EEValues=
    LastContact=12/25/2010 6:12:29 PM
    TotalInteractions=5
    FailedInteractions=5
    Protocol=1
    [Device 2]
    DeviceID=0A.BB.3D
    DeviceName=Tap-Added LampLinc V2 2-Pin 1
    DeviceLocation=Unknown
    PollingInterval=0
    DeviceType=0106
    FirmwareVer=32
    DatabaseDelta=-1
    LinksDownloaded=0

    --------*End C:\Program Files\HomeSeer HS2\Config\Insteon.ini*--------------











    #2
    thanks for the comprehensive report. I should be about to fix the x10 preset issue.

    As for the second bug related to the NAKs, did you see the same thing with v1.5.2?
    Mark

    HS3 Pro 4.2.19.5
    Hardware: Insteon Serial PLM | AD2USB for Vista Alarm | HAI Omnistat2 | 1-Wire HA7E | RFXrec433 | Dahua Cameras | LiftMaster Internet Gateway | Tuya Smart Plugs
    Plugins: Insteon (mine) | Vista Alarm (mine) | Omnistat 3 | Ultra1Wire3 | RFXCOM | HS MyQ | BLRadar | BLDenon | Tuya | Jon00 Charting | Jon00 Links
    Platform: Windows Server 2022 Standard, i5-12600K/3.7GHz/10 core, 16GB RAM, 500GB SSD

    Comment


      #3
      PLM NAKs

      Hi Mark,

      Thanks for the quick response. Based on your request for more info on the NAKs, and how they related to driver version, I did some more experimenting. Below are test results with both the old and new Insteon Drivers.

      This time, I'm providing output from the serial port monitor with timestamps. It gives a better idea of the handshaking between the driver and the PLM.

      Below is the Serial Port Monitor capture with the 1.4.? Insteon Driver. House code C1 is being sent a Preset Dim command.

      Note that driver sends 1 byte at a time and waits for a response (echo) before proceeding. This example shows that the driver successfully sends the entire first phase with the HCUC, with each byte being echoed, and the final byte being ACK'd. However, when the driver sends the SOM (0x02) of the second phase, the PLM NAKs it immediately. The driver waits 1/3 of a second and then retries. While this example shows just one NAK, most of the time there are actually two SOM attempts with NAKs before a successful transmission.

      Request: 12/26/2010 1:17:20 PM.65464 (+81.2615 seconds)

      02 .

      Answer: 12/26/2010 1:17:20 PM.68664 (+0.0312 seconds)

      02 .

      Request: 12/26/2010 1:17:20 PM.77964 (+0.0937 seconds)

      63 c

      Answer: 12/26/2010 1:17:20 PM.79564 (+0.0156 seconds)

      63 c

      Request: 12/26/2010 1:17:20 PM.85864 (+0.0625 seconds)

      26 &

      Answer: 12/26/2010 1:17:20 PM.93664 (+0.0781 seconds)

      26 &

      Request: 12/26/2010 1:17:20 PM.93664 (+0.0000 seconds)

      00 .

      Answer: 12/26/2010 1:17:20 PM.06164 (+0.1250 seconds)

      00 06 .. End of first phase with the 0x06 ACK

      Request: 12/26/2010 1:17:20 PM.20164 (+0.0000 seconds)

      02 . SOM of second phase

      Answer: 12/26/2010 1:17:20 PM.26464 (+0.0625 seconds)

      15 . SOM is NAK'd by the PLM

      Request: 12/26/2010 1:17:20 PM.57664 (+0.3125 seconds)

      02 . Retry

      Answer: 12/26/2010 1:17:20 PM.60864 (+0.0312 seconds)

      02 . Accepted this time

      Request: 12/26/2010 1:17:20 PM.60864 (+0.0000 seconds)

      63 c Message continues

      Answer: 12/26/2010 1:17:21 PM.62364 (+0.0156 seconds)

      63 c

      Request: 12/26/2010 1:17:21 PM.63964 (+0.0156 seconds)

      0A .

      Answer: 12/26/2010 1:17:21 PM.65464 (+0.0156 seconds)

      0A .

      Request: 12/26/2010 1:17:21 PM.65464 (+0.0000 seconds)

      80 ?

      Answer: 12/26/2010 1:17:21 PM.67064 (+0.0156 seconds)

      80 06 ?. Message concludes with a 0x06 ACK



      ----------------------

      Now, with the 1.5.2.0 driver, the driver sends all bytes of a complete X10 Raw message phase before looking for any response. The PLM appears to also wait until all bytes have been received before echoing and ACKing them or before NAKing them. If it NAKs them, it doesn't echo any of them. It just sends the 0x15 NAK.

      This command is to HCUC C1, with a Preset DIM.

      Request: 12/26/2010 1:25:49 PM.35064 (+92.1047 seconds)

      02 63 26 00 .c&. First Phase indicating HCUC C1

      Answer: 12/26/2010 1:25:49 PM.63264 (+0.2812 seconds)

      02 63 26 00 06 .c&.. PLM response echoing with a 0x06 ACK. Note .2812 second delay for transmission and processing time.

      Request: 12/26/2010 1:25:49 PM.64764 (+0.0000 seconds)

      02 63 0B 80 .c.? Second Phase to preset DIM to 52% (wrong value)

      Answer: 12/26/2010 1:25:49 PM.71064 (+0.0625 seconds)

      15 . PLM does NOT echo it, but does NAK it.

      Request: 12/26/2010 1:25:50 PM.03864 (+1.3281 seconds)

      02 63 0B 80 .c.? Driver delays over 1 second and then resends due to the NAK

      Answer: 12/26/2010 1:25:50 PM.08564 (+0.0469 seconds)

      02 63 0B 80 06 .c.?. PLM echoes and ACKs it this time.


      Here's another one with the same driver. This time, the PLM sends two NAKs after receiving the second phase message once:


      Request: 12/26/2010 1:39:40 PM.05564 (+439.2347 seconds)

      02 63 26 00 .c&. First Phase Message

      Answer: 12/26/2010 1:39:40 PM.07064 (+0.0156 seconds)

      02 63 26 00 06 .c&.. Echo and ACK

      Request: 12/26/2010 1:39:40 PM.07064 (+0.0000 seconds)

      02 63 0B 80 .c.? Second Phase Message

      Answer: 12/26/2010 1:39:40 PM.10164 (+0.0312 seconds)

      15 15 .. NAK'd twice

      Request: 12/26/2010 1:39:42 PM.38364 (+1.2812 seconds)

      02 63 0B 80 .c.? Second Phase message resend

      Answer: 12/26/2010 1:39:42 PM.39864 (+0.0156 seconds)

      02 63 0B 80 06 .c.?. Echo and ACk




      The bottom line is that it seems like it is normal operation for the PLM to NAK things between the first and second phases. My guess is that this is, in effect, an "I'm not ready, please try again" NAK. On the older driver, when the SOM is sent for the second phase, I often see the SOM NAK'd twice before it is accepted on the third attempt. However, sometimes, it is only NAK'd once (as shown). On the newer driver, since the driver sends the whole phase message before looking for an echo or a NAK, I usually see just one NAK after the first attempt to send the second phase (first example of 1.5.2). However, sometimes the PLM sends two NAKs (second example of 1.5.2). The driver, however, responds with just one resend in either case.

      I think the driver is actually operating correctly here (not breaking any rules). It is the PLM that is NAKing, which is causing the driver to retransmit. I'm not sure why the PLM NAKs, but I'm assuming it is normal operation. Based on my theory that the NAKs are being sent because the PLM is not yet ready to handle the next message, total system operation could perhaps be optimized by the driver if it added a small delay between the first and second phase transmissions to allow the PLM to 'catch up' without blocking via the NAK. Some experimentation to find the right delay would likely be required.

      Thanks again, Mark, for looking at this Preset Dim problem. And if you optimize the inter-phase delay, that would be another plus, but now that I've looked at it in more detail, I don't think it is a major problem.

      Comment


        #4
        You are correct, the plm will NAK a msg if it is not ready to receive. And once this happens, the plugin must wait before resending (typically 250 msecs). This is part of the PLM protocol. I believe the plm requires a send and wait for ACK or NAK when transmitting a msg because the next likely msgs is the response from the target device itself. so I need to wait for the plm ack/nak before i can expect a target device response. hope this makes sense.

        There are two timing config options (see below) you can play with each is in msecs. Add the following section to your insteon.ini. You should be able to changes these dynamically so restarting hs each time is not necessary.

        [Tuning]
        ;this is the wait time before resending
        PLMClearDelay=250

        ;this is the processing time to clear the plm recv buffer before sending a new msg
        SettleTime=200
        Mark

        HS3 Pro 4.2.19.5
        Hardware: Insteon Serial PLM | AD2USB for Vista Alarm | HAI Omnistat2 | 1-Wire HA7E | RFXrec433 | Dahua Cameras | LiftMaster Internet Gateway | Tuya Smart Plugs
        Plugins: Insteon (mine) | Vista Alarm (mine) | Omnistat 3 | Ultra1Wire3 | RFXCOM | HS MyQ | BLRadar | BLDenon | Tuya | Jon00 Charting | Jon00 Links
        Platform: Windows Server 2022 Standard, i5-12600K/3.7GHz/10 core, 16GB RAM, 500GB SSD

        Comment


          #5
          I fixed the X10 Preset Dim according to the Insteon PLM programmers guide. The 3rd byte cmds i'm sending are a little different than what you suggested but i think they are right for the PLM.

          I also added a .5 sec delay between x10 TX cmds which seems to reduce the PLM NAKs quite a bit.

          Let me know what you think

          PS the standard x10 Dim and Bright cmds still don't seem to work correctly.
          Attached Files
          Mark

          HS3 Pro 4.2.19.5
          Hardware: Insteon Serial PLM | AD2USB for Vista Alarm | HAI Omnistat2 | 1-Wire HA7E | RFXrec433 | Dahua Cameras | LiftMaster Internet Gateway | Tuya Smart Plugs
          Plugins: Insteon (mine) | Vista Alarm (mine) | Omnistat 3 | Ultra1Wire3 | RFXCOM | HS MyQ | BLRadar | BLDenon | Tuya | Jon00 Charting | Jon00 Links
          Platform: Windows Server 2022 Standard, i5-12600K/3.7GHz/10 core, 16GB RAM, 500GB SSD

          Comment


            #6
            I had the NAK problem often with my old PLM. . and that was on the 1.4.x versions of the plugin and also the 1.5.x versions of the plugin.. those issues seem to go completely away when I bought a new PLM about 2 months ago or so... (i use the dual band serial version)...

            as for my smarthome devices failing.. unfortunately I have started to lose some 2476's that were several years old.. of course they were outside the 3 year warranty.. but to me a dimmer should last longer than 3 years and a few weeks....

            that said, I have a whole drawer of 2380W's in white if you need some... and a couple keypadlinc's too..

            -Christopher
            PerfecTemp - the Most advanced HVAC system I've ever Built - and its in my House

            Comment


              #7
              Originally posted by cadillackid View Post
              I had the NAK problem often with my old PLM. . and that was on the 1.4.x versions of the plugin and also the 1.5.x versions of the plugin.. those issues seem to go completely away when I bought a new PLM about 2 months ago or so... (i use the dual band serial version)...

              as for my smarthome devices failing.. unfortunately I have started to lose some 2476's that were several years old.. of course they were outside the 3 year warranty.. but to me a dimmer should last longer than 3 years and a few weeks....

              that said, I have a whole drawer of 2380W's in white if you need some... and a couple keypadlinc's too..

              -Christopher
              Christopher

              are any of the keypadlincs still working? I like to have an extra kpl around for testing, etc.
              Mark

              HS3 Pro 4.2.19.5
              Hardware: Insteon Serial PLM | AD2USB for Vista Alarm | HAI Omnistat2 | 1-Wire HA7E | RFXrec433 | Dahua Cameras | LiftMaster Internet Gateway | Tuya Smart Plugs
              Plugins: Insteon (mine) | Vista Alarm (mine) | Omnistat 3 | Ultra1Wire3 | RFXCOM | HS MyQ | BLRadar | BLDenon | Tuya | Jon00 Charting | Jon00 Links
              Platform: Windows Server 2022 Standard, i5-12600K/3.7GHz/10 core, 16GB RAM, 500GB SSD

              Comment


                #8
                X10 Preset Dim Problem Resolved (I think)

                Hi Mark,

                I tried the new version of the plugin (1.5.2.12), and so far, it seems to be dimming my lights correctly. I haven't tried programming any of my older X10 Switchlincs yet, and I haven't looked at the data being sent to the PLM yet, but my guess is that you fixed things correctly. I'll let you know if I run into any more problems.

                Thanks very much for doing this!

                Brook

                Comment


                  #9
                  I just replaced my 1132cu with a 2413u and am having similar problems with dimming x10 devices (I have not moved on to check on recieving x10 signals yet), so I tried the 1.5.2.12 you uploaded to replace 1.4.2, and it won't start saying my license has expired. What am I missing?

                  Thanks

                  Comment


                    #10
                    Originally posted by cycleguy View Post
                    I just replaced my 1132cu with a 2413u and am having similar problems with dimming x10 devices (I have not moved on to check on recieving x10 signals yet), so I tried the 1.5.2.12 you uploaded to replace 1.4.2, and it won't start saying my license has expired. What am I missing?

                    Thanks
                    Versions 1.5+ require a license. You should download v1.5.5 (which includes a 30day trial license) if you are interested in upgrading.
                    Mark

                    HS3 Pro 4.2.19.5
                    Hardware: Insteon Serial PLM | AD2USB for Vista Alarm | HAI Omnistat2 | 1-Wire HA7E | RFXrec433 | Dahua Cameras | LiftMaster Internet Gateway | Tuya Smart Plugs
                    Plugins: Insteon (mine) | Vista Alarm (mine) | Omnistat 3 | Ultra1Wire3 | RFXCOM | HS MyQ | BLRadar | BLDenon | Tuya | Jon00 Charting | Jon00 Links
                    Platform: Windows Server 2022 Standard, i5-12600K/3.7GHz/10 core, 16GB RAM, 500GB SSD

                    Comment


                      #11
                      Kind of sucks that 1.4.2 won't control x-10 though...I'll look into the option of purchasing yet another license.

                      Comment


                        #12
                        Not that many people actually use the plugin for x10 so these issues didn't arise earlier.
                        Mark

                        HS3 Pro 4.2.19.5
                        Hardware: Insteon Serial PLM | AD2USB for Vista Alarm | HAI Omnistat2 | 1-Wire HA7E | RFXrec433 | Dahua Cameras | LiftMaster Internet Gateway | Tuya Smart Plugs
                        Plugins: Insteon (mine) | Vista Alarm (mine) | Omnistat 3 | Ultra1Wire3 | RFXCOM | HS MyQ | BLRadar | BLDenon | Tuya | Jon00 Charting | Jon00 Links
                        Platform: Windows Server 2022 Standard, i5-12600K/3.7GHz/10 core, 16GB RAM, 500GB SSD

                        Comment

                        Working...
                        X