Announcement

Collapse
No announcement yet.

PoE Z-Wave 800 Controller Network Unit

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

    #61
    Originally posted by PFL View Post

    The Z-NET would allow one session only. You can't connect mutiple HS4 to one Z-NET.
    Are you stating your board can connect to more than one active HS4 instance simultaneously?

    HS4 Pro, 4.2.19.0 Windows 10 pro, Supermicro LP Xeon

    Comment


      #62
      Originally posted by randy View Post
      Are you stating your board can connect to more than one active HS4 instance simultaneously?
      Yes. As long as HomeSeer not modify their HS4.

      Comment


        #63
        Well, ser2net can be configured to allow multiple network clients to connect to a single serial resource as well.

        However, if two HS instances were to connect to the same endpoint, chaos would result. The protocol isn't designed to support this.

        Generally, expecting point-to-point serial endpoints to work in a multidrop configuration is inviting disappointment. This is Serial-101.

        Comment


          #64
          Originally posted by zwolfpack View Post
          Well, ser2net can be configured to allow multiple network clients to connect to a single serial resource as well.

          However, if two HS instances were to connect to the same endpoint, chaos would result. The protocol isn't designed to support this.

          Generally, expecting point-to-point serial endpoints to work in a multidrop configuration is inviting disappointment. This is Serial-101.
          Generally, you are right. But as the application like HS4, the communications are good because of ZGM230S has buffer to queue those data. You can test them to see how it works. The only issue is the status of the controlled devices when you use multiple instances to control them differently.

          Comment


            #65
            Originally posted by PFL View Post

            Generally, you are right. But as the application like HS4, the communications are good because of ZGM230S has buffer to queue those data.
            You're missing the point. The application protocol doesn't support this. All the buffering in the world at a lower layer isn't going to solve this.

            You can test them to see how it works.
            I'll give this product a wide berth so won't be doing any testing. But have you? For instance, for two simultaneously connected instances HS_1 and HS_2
            1) If HS_1 turns on light, is that change reflected in HS_2? For that matter, does the light turn on reliably and is that status reliably reflected in HS_1?
            2) If a motion sensor is triggered or temperature sensor updated, is that status reliably reflected in both HS_1 and HS_2?
            3) If a node is added or removed in HS_1, are corresponding devices added/removed at both HS_1 and HS_2?

            The only issue is the status of the controlled devices when you use multiple instances to control them differently.
            I suspect there are plenty more issues.

            Comment


              #66
              Originally posted by zwolfpack View Post

              You're missing the point. The application protocol doesn't support this. All the buffering in the world at a lower layer isn't going to solve this.


              I'll give this product a wide berth so won't be doing any testing. But have you? For instance, for two simultaneously connected instances HS_1 and HS_2
              1) If HS_1 turns on light, is that change reflected in HS_2? For that matter, does the light turn on reliably and is that status reliably reflected in HS_1?
              2) If a motion sensor is triggered or temperature sensor updated, is that status reliably reflected in both HS_1 and HS_2?
              3) If a node is added or removed in HS_1, are corresponding devices added/removed at both HS_1 and HS_2?


              I suspect there are plenty more issues.
              I did the test, both HS4 Pro, one is installed on Pi 5, One is installed on windows 11. HS_1 turns on light, HS_2 turns off, the light will be on then off. I didn't test motion sensor, but the temperature and voltage, current would update both HS instances normally without any issue.
              In another word, both systems work reliably

              Comment


                #67
                Originally posted by zwolfpack View Post

                You're missing the point. The application protocol doesn't support this. All the buffering in the world at a lower layer isn't going to solve this.


                I'll give this product a wide berth so won't be doing any testing. But have you? For instance, for two simultaneously connected instances HS_1 and HS_2
                1) If HS_1 turns on light, is that change reflected in HS_2? For that matter, does the light turn on reliably and is that status reliably reflected in HS_1?
                2) If a motion sensor is triggered or temperature sensor updated, is that status reliably reflected in both HS_1 and HS_2?
                3) If a node is added or removed in HS_1, are corresponding devices added/removed at both HS_1 and HS_2?


                I suspect there are plenty more issues.
                There are 2 communication protocals: UART communication and Z-Wave communication, UART is between controller and Host, that is buffered. Z-Wave communication is controlled by the controller. There is no any messed up on the communications.

                Comment


                  #68
                  Maybe you are asking the ethernet communication, the protocol is TCP/IP, it's between Host and FPGA.

                  Comment


                    #69
                    Test motion sensor. This is a better test than temperature, voltage, current as those send updates periodically.
                    Test add/remove node.
                    Test situations where commands can be sent simultaneously for both systems.
                    Run tests over multiple iterations (100+) to verify reliability.

                    Comment


                      #70
                      Originally posted by zwolfpack View Post
                      Test motion sensor. This is a better test than temperature, voltage, current as those send updates periodically.
                      Test add/remove node.
                      Test situations where commands can be sent simultaneously for both systems.
                      Run tests over multiple iterations (100+) to verify reliability.
                      I don't think there is any problem exist. Because ethernet uses Carrier-sense multiple access with collision detection (CSMA/CD), and UART transmits data Asynchronously. So there is no any data collision.
                      Please let me know the results after you did all the tests.

                      Comment


                        #71
                        Originally posted by PFL View Post

                        I don't think there is any problem exist. Because ethernet uses Carrier-sense multiple access with collision detection (CSMA/CD), and UART transmits data Asynchronously. So there is no any data collision.
                        Oh goodness this is utter nonsense.

                        To begin with, CSMA/CD has been deprecated from Ethernet for years.

                        The Ethernet layer has no bearing on data ordering at the application layer(s). You have your OSI layers more scrambled than a three-egg breakfast.

                        Please let me know the results after you did all the tests.
                        You'll have to rope in some unintended alpha-testers. I don't own, nor will have anything to do with this hardware.​

                        Comment


                          #72
                          Originally posted by zwolfpack View Post

                          Oh goodness this is utter nonsense.

                          To begin with, CSMA/CD has been deprecated from Ethernet for years.

                          The Ethernet layer has no bearing on data ordering at the application layer(s). You have your OSI layers more scrambled than a three-egg breakfast.

                          Well, it looks like you're a programmer, The multi-Access is on MAC layer or physic layer, the application layer is not deal with the data sequence and addressing, routing etc.

                          ​[/QUOTE]
                          You'll have to rope in some unintended alpha-testers. I don't own, nor will have anything to do with this hardware.​
                          ​[/QUOTE]

                          You could modify your Z-NET ser2net parameter to do the test, if you want. I know this is working so i just did the simple tests.

                          Comment

                          Working...
                          X