Announcement

Collapse
No announcement yet.

UPB Plug-in - Beta Testing

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

  • #31
    V5 ~75%

    So, have you tested the UMI with 3.0.0.5? Does it work fine?
    Spud:

    UpStart Definition
    With regards to UpStart (US), the program itself has always seemed a little odd.
    Putting aside its “cutesy dialogs”, how US specifies the UMIs input and outputs is backward.


    Going forward I will refer to-
    The three channels that respond to external stimuli as Inputs.
    The two channels that provide contact closure are Outputs.


    Summary:
    The PI appears to be ~75% functional.
    -All 5 channels appear

    -Input channels 1 and 3 respond
    -Input channel 2 does not

    -Output channels 1 and 2 have not been tested

    -The links don’t appear to respond either as they did with the HS2 PI. At this time that is not an issue.

    The means of testing may be affecting channel 2. See “Trigger Issue?” below

    I will move the UMI and the attached wiring panel from the cramped upper corner in the server room to a “lab” environment. With the assembly sitting next to my HS3 box the testing can be more precise.

    If I remember correctly you are using borrowed equipment. I respect the timeline that imposes.
    More detail should be available tomorrow morning.


    Detail:


    Because the family home is home today, the testing that least degrades WAF is to leave the garage doors alone.

    Normally when testing like this, the modified CAT5 cable that travels to the garage is unplugged from the assembly. A dummy cable is used in it’s place.

    Trigger Issue?
    The dummy cable when plugged in completes the voltage sense for channels 1 and 2, illuminating the two UMI LED channel indicators simultaneously. Channel 3 is on a separate connector to the assembly and is not an issue. It is because of the cramped quarters that the dummy was made.

    It is the simultaneous action on channels 1 and 2 that **may** be why Input 2's state change is not appearing in the PI.

    Making a Channel 1 and a Channel 2 dummy would be faster than moving the assembly.

    However….

    In the US options for the UMI the Output channels are specified as momentary. I need to stand next to the UMI to see how the PI responds for those two seconds.

    T
    Last edited by tam; November 28th, 2013, 02:45 PM. Reason: Clarification

    Comment


    • #32
      V5 ~ 35% Functional

      Spud:

      I created from scratch an UpStart config with just two devices, the UMI and a wall switch which controls the office lights.

      Minimal links

      All tested fine in UpStart
      In 1 closed - lights 10%
      In 1 open - lights off
      In 2 closed - lights 40%
      In 2 open - lights off
      In 3 closed - lights 80%
      In 3 open - lights off

      In the PI:
      Input 1 is ON all the time
      Input 2 is OFF all the time
      Input 3 is OFF all the time
      ...no matter what Input is closed.
      But, the office lights responded exactly as they did when tested in UpStart

      The PI accurately shows the illumination of the lights for each UMI input state

      Also, Out 1's state always changes to ON, when ever any Input is closed.
      Out 1's state changes back to OFF when that Input is again open

      Out1 and Out2 both function normally when clicking them ON/OFF via the PI.

      I have attached the UPE and 16 pages of screen shots to assist with this.

      Let me know how I can further assist.

      Terry
      Attached Files

      Comment


      • #33
        thank you for the tests!

        Please try version 3.0.0.6 attached to first post of this thread. I believe I have fixed some of the bugs you reported.

        Comment


        • #34
          98% Functional

          The 2% may be an UpStart thing. I will test further.

          All the problems listed before have been fixed.

          I just registered.

          Thanks

          Terry

          Comment


          • #35

            Comment


            • #36
              Cool, thank you for all the tests!

              Comment


              • #37
                So far all is stable and very quick. This is a great plugin. Thanks.

                Comment


                • #38
                  Hello Spud,

                  Went to update today to most current version of the plugin as posted in the OP.

                  Seeing this error.

                  Please wait for the updater control file failed to be downloaded or parsed.
                  If I remove the "updater_override.txt" I see all of the regular HS3 plugins.

                  I did disable and delete the old version of the plugin.

                  I do notice that your plugin version dot 4 is showing up in the updater now.

                  I installed the one from the Updater. Disabled it and tried to update with most current OP file V.6.

                  I am still getting the above mentioned error and cannot install most current update.
                  Last edited by Pete; November 30th, 2013, 01:45 PM.
                  - Pete

                  Auto mator
                  Homeseer 3 Pro - 3.0.0.534 (Linux) - Ubuntu 18.04/W7e 64 bit Intel Haswell CPU - Mono 6.00
                  Homeseer Zee2 (Lite) - 3.0.0.534 (Linux) - Ubuntu 18.04/W7e - CherryTrail x5-Z8350 BeeLink 4Gb BT3 Pro - Mono 6.00

                  X10, UPB, Zigbee, ZWave and Wifi MQTT automation.

                  Comment


                  • #39
                    strange, just tested reinstalling .6 on windows and all went fine.

                    anyway to upgrade you can just unzip, then copy UPB4CSharp.dll to bin/UPB and HSPI_UPBSpud.exe to your HS3 root. All the other files haven't changed.

                    Comment


                    • #40
                      Thank-you Spud.

                      Shut down HS3. Updated files from zip. Restarted HS3 and all is OK.

                      Not sure what the issue was the "updater_override.txt" file ; that said the download of V.4 from the updater worked fine for me originally; even though it was a downgrade from V.5.
                      Last edited by Pete; November 30th, 2013, 05:26 PM.
                      - Pete

                      Auto mator
                      Homeseer 3 Pro - 3.0.0.534 (Linux) - Ubuntu 18.04/W7e 64 bit Intel Haswell CPU - Mono 6.00
                      Homeseer Zee2 (Lite) - 3.0.0.534 (Linux) - Ubuntu 18.04/W7e - CherryTrail x5-Z8350 BeeLink 4Gb BT3 Pro - Mono 6.00

                      X10, UPB, Zigbee, ZWave and Wifi MQTT automation.

                      Comment


                      • #41
                        Device Off and On via script

                        Ok, so with HS2, we had the ability to set a device off and on via a script via execX10ByName. With HS3, I think that is gone. With that said, I ASSUME that we are now to use setDeviceValue to say 0 and 100 to represent off and on? With that said, via script, I used SetDeviceValueByName to set a devices value to 100, but the UPB device did not turn on. I did confirm the device value to change to 100. Should UPB devices response to device value changes? If not, what is the proper way to now turn on, off and DIM a UPB device via a script?
                        HS: 2.5.0.60
                        Environment: Virtual XP as guest in VMWare Server running under Win 7
                        Plug-ins: MLHSPlugin|RCS Serial Thermostat|UltraLog|UltraMon|
                        Misc: 303 Devices, 313 Events, 68+ Scripts

                        HSeer: 3.0.0.54
                        Environment: Virtual XP as guest in VMWare Server running under Win 7
                        Plug-ins: BLGData|BLRF|BLRadar|BLRandom|BLSpeech
                        UltraM1G3|UltraECM3|UltraMon3|UPBSpud|Z-Wave
                        Misc: 148 Devices, 116 Events, 9+ Scripts (so far, still converting)

                        Comment


                        • #42
                          Originally posted by jstaab View Post
                          Ok, so with HS2, we had the ability to set a device off and on via a script via execX10ByName. With HS3, I think that is gone. With that said, I ASSUME that we are now to use setDeviceValue to say 0 and 100 to represent off and on? With that said, via script, I used SetDeviceValueByName to set a devices value to 100, but the UPB device did not turn on. I did confirm the device value to change to 100. Should UPB devices response to device value changes? If not, what is the proper way to now turn on, off and DIM a UPB device via a script?
                          I think the right way to do this in HS3 is to use the Device Control API (CAPI). Some examples here: http://board.homeseer.com/showthread...ht=CAPIControl

                          Alternatively I could add to the plugin some public functions accessible by script like TurnDeviceOn, TurnDeviceOff, etc...

                          Comment


                          • #43
                            Geese so there isn't a single line to turn on and off a device by its name!? Good grief.

                            Sent from my SCH-I45 using Tapatalk
                            HS: 2.5.0.60
                            Environment: Virtual XP as guest in VMWare Server running under Win 7
                            Plug-ins: MLHSPlugin|RCS Serial Thermostat|UltraLog|UltraMon|
                            Misc: 303 Devices, 313 Events, 68+ Scripts

                            HSeer: 3.0.0.54
                            Environment: Virtual XP as guest in VMWare Server running under Win 7
                            Plug-ins: BLGData|BLRF|BLRadar|BLRandom|BLSpeech
                            UltraM1G3|UltraECM3|UltraMon3|UPBSpud|Z-Wave
                            Misc: 148 Devices, 116 Events, 9+ Scripts (so far, still converting)

                            Comment


                            • #44
                              I have a UPB device that I might be able to control one time, then stops working. Looking at your debug log, it appears that everything looks normal, even though it still isn't working. What information do you need to figure out what might be up? At the moment, I'm simply using the web interface to control the device to keep it simple.
                              Thanks!
                              HS: 2.5.0.60
                              Environment: Virtual XP as guest in VMWare Server running under Win 7
                              Plug-ins: MLHSPlugin|RCS Serial Thermostat|UltraLog|UltraMon|
                              Misc: 303 Devices, 313 Events, 68+ Scripts

                              HSeer: 3.0.0.54
                              Environment: Virtual XP as guest in VMWare Server running under Win 7
                              Plug-ins: BLGData|BLRF|BLRadar|BLRandom|BLSpeech
                              UltraM1G3|UltraECM3|UltraMon3|UPBSpud|Z-Wave
                              Misc: 148 Devices, 116 Events, 9+ Scripts (so far, still converting)

                              Comment


                              • #45
                                Attached my export file. The device in question is the master bedroom fan. In the web interface, an On and Off button is displaying to control it, but basically I managed to turn it on, once, then that's it, it no longer responds. I did confirm, the PIM is transmitting, so the only thing I can conclude is that something in the addressing or the command isn't quite right. Under HS2, I do not have any issues controlling this device.
                                Thanks for your help!

                                EDIT, debug below, and in addition, I deleted the device, re-imported, I could control it twice, but the device update in the web interface really lags, that is, the icon showing the states lags behind the action. Once it stops updating and gets out of sync with the actual state of the device, then you can no longer control it.
                                Dec-02 10:19:24 PM UPBSpud DEBUG PIM_SEND:: Resuming sending after waiting a refreshing 600ms
                                Dec-02 10:19:23 PM UPBSpud DEBUG PIM_SEND:: Pausing because last command expected a reply
                                Dec-02 10:19:23 PM UPBSpud DEBUG PIM_SEND:: Message ID 48 confirmed sent successfully
                                Dec-02 10:19:23 PM UPBSpud DEBUG PIM_SEND:: UPB Device ACK'd current message (ID=48)
                                Dec-02 10:19:22 PM UPBSpud DEBUG PIM_SEND:: PIM ACK'd current message (ID=48)
                                Dec-02 10:19:22 PM UPBSpud DEBUG PIM_SEND:: ABOUT_TO_SEND[0714010AFF30AB{0xD}]
                                Dec-02 10:19:22 PM UPBSpud DEBUG PIM_SEND:: Sending Message ID 48 to PIM, retry count=0
                                Dec-02 10:19:22 PM UPBSpud DEBUG PIM_SEND:: Extracted next message to send from queue (ID 48)
                                Dec-02 10:19:22 PM UPBSpud DEBUG DEVICE[10]:: Confirmed request to set device to level succeedded -- updating internal state
                                Dec-02 10:19:22 PM UPBSpud DEBUG UPB_MGR:: passing queueMessage for UPB message to media-adapter
                                Dec-02 10:19:22 PM UPBSpud DEBUG UPB_MGR:: STATE_QUEUE:: Sending state queury for device Fan (10)
                                Dec-02 10:19:22 PM UPBSpud DEBUG DEVICE[10]:: Got request to set light to non-normative level -- queueing status request to confirm
                                Dec-02 10:19:22 PM UPBSpud DEBUG PIMADAPTER:: Confirmed message to device succeeded
                                Dec-02 10:19:22 PM UPBSpud DEBUG PIM_SEND:: Message ID 44 confirmed sent successfully
                                Dec-02 10:19:22 PM UPBSpud DEBUG PIM_SEND:: UPB Device ACK'd current message (ID=44)
                                Dec-02 10:19:22 PM UPBSpud DEBUG PIM_SEND:: PIM ACK'd current message (ID=44)
                                Dec-02 10:19:22 PM UPBSpud DEBUG PIM_SEND:: ABOUT_TO_SEND[0814010AFF226454{0xD}]
                                Dec-02 10:19:22 PM UPBSpud DEBUG PIMADAPTER:: Confirmed message marked as being sent, timeout timer has 10000 millis left
                                Dec-02 10:19:22 PM UPBSpud DEBUG PIM_SEND:: Sending Message ID 44 to PIM, retry count=0
                                Dec-02 10:19:22 PM UPBSpud DEBUG PIM_SEND:: Extracted next message to send from queue (ID 44)
                                Dec-02 10:19:22 PM UPBSpud DEBUG PIMADAPTER:: Got update on Confirmed message, but still not sent to PIM yet
                                Dec-02 10:19:22 PM UPBSpud DEBUG UPB_MGR:: passing sendConfirmedMessage for UPB message to media-adapter
                                Dec-02 10:19:21 PM Device Control Device: Master Bedroom Fan to On (100) by/from: CAPI Control Handler
                                Attached Files
                                Last edited by jstaab; December 2nd, 2013, 11:23 PM.
                                HS: 2.5.0.60
                                Environment: Virtual XP as guest in VMWare Server running under Win 7
                                Plug-ins: MLHSPlugin|RCS Serial Thermostat|UltraLog|UltraMon|
                                Misc: 303 Devices, 313 Events, 68+ Scripts

                                HSeer: 3.0.0.54
                                Environment: Virtual XP as guest in VMWare Server running under Win 7
                                Plug-ins: BLGData|BLRF|BLRadar|BLRandom|BLSpeech
                                UltraM1G3|UltraECM3|UltraMon3|UPBSpud|Z-Wave
                                Misc: 148 Devices, 116 Events, 9+ Scripts (so far, still converting)

                                Comment

                                Working...
                                X