Skip to content
  • MySensors
  • OpenHardware.io
  • Categories
  • Recent
  • Tags
  • Popular
Skins
  • Light
  • Brite
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Default (No Skin)
  • No Skin
Collapse
Brand Logo
  1. Home
  2. Controllers
  3. OpenHAB
  4. openHAB 2.0 binding

openHAB 2.0 binding

Scheduled Pinned Locked Moved OpenHAB
534 Posts 88 Posters 479.6k Views 99 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • Q Offline
    Q Offline
    Qu3Uk
    wrote on last edited by Qu3Uk
    #131

    I seem to be having some issues with the dimmer function and I'm not entirely sure if its OpenHab, the binding or MySensors... but I seem to be able to crash the gateway once OpenHab boots up... The node is basically running DimmerLED stretch

    20:31:13.030 [DEBUG] [g.mysensors.protocol.MySensorsReader] - 7;1;1;0;0;33.8
    ...
    20:31:13.596 [INFO ] [smarthome.event.ItemCommandEvent    ] - Item 'Light_APT_Lounge_TV' received command ON
    20:31:13.598 [DEBUG] [g.mysensors.protocol.MySensorsWriter] - Sending to MySensors: 8;0;1;0;2;1
    20:31:13.602 [INFO ] [marthome.event.ItemStateChangedEvent] - Light_APT_Lounge_TV changed from NULL to 100
    20:31:14.599 [DEBUG] [g.mysensors.protocol.MySensorsReader] - 0;0;3;0;14;Gateway startup complete.
    20:31:27.963 [WARN ] [g.mysensors.protocol.MySensorsReader] - Connection to Gateway lost!
    20:31:27.964 [DEBUG] [g.mysensors.protocol.MySensorsReader] - Stopping Reader thread
    20:31:27.965 [INFO ] [me.event.ThingStatusInfoChangedEvent] - 'mysensors:bridge-eth:gateway' changed from ONLINE to OFFLINE
    

    I notice the ItemState is null and that sort of makes sense why if OpenHab has been restarted but surely if it is null it shouldn't cause the gateway to go offline? Also it doesn't reconnect which is probably more of an issue.

    
    Bridge mysensors:bridge-eth:gateway [ ipAddress="192.168.1.150", tcpPort=5003, sendDelay=200 ] {
            	dimmer			light08	[ nodeId="8", childId="0" ]	
    }
    
    

    Items

    Dimmer	Light_APT_Lounge_TV	"TV Lights"	<light>	(Lights, APT_Lounge)	{ channel="mysensors:dimmer:gateway:light08:dimmer" }
    
    
    1 Reply Last reply
    0
    • T Offline
      T Offline
      TimO
      Hero Member
      wrote on last edited by
      #132

      I finally found some time to develop on the binding.

      A new version is available with the following changes:

      • On startup the binding will request I_VERSION from gateway to ensure its proper startup. Thanks @andreacioni for the PR!!

      • HVAC (V_VAR1, V_VAR2 ...) are now available. Thanks @Denke for the PR!!

      • The request for ACK feature is now available for testing. It works for light/status for me. If a message is NOT acknowledged by a node the binding retries to send the message five times. If no ACK is received after that the binding will try to revert the item to its old state. This only works, if a state is known (not NULL, for example at startup).

      Additionally I've tested the binding with multiple gateways (one EthernetGW, one SerialGW), works fine.

      G 1 Reply Last reply
      3
      • T TimO

        I finally found some time to develop on the binding.

        A new version is available with the following changes:

        • On startup the binding will request I_VERSION from gateway to ensure its proper startup. Thanks @andreacioni for the PR!!

        • HVAC (V_VAR1, V_VAR2 ...) are now available. Thanks @Denke for the PR!!

        • The request for ACK feature is now available for testing. It works for light/status for me. If a message is NOT acknowledged by a node the binding retries to send the message five times. If no ACK is received after that the binding will try to revert the item to its old state. This only works, if a state is known (not NULL, for example at startup).

        Additionally I've tested the binding with multiple gateways (one EthernetGW, one SerialGW), works fine.

        G Offline
        G Offline
        gonzalonal
        wrote on last edited by gonzalonal
        #133

        Hi @TimO.
        I have just installed the new release and I believe I've found a little bug. I am using Serial Gateway with version 1.5.3

        At boot up time, I am getting the followinf error:

        03:07:52.644 [ERROR] [s.internal.MySensorsBridgeConnection] - Cannot start reading/writing thread, probably sync message (I_VERSION) not received
        

        I have read that this new release, request the gateway for its version so as to prove proper start up.

        What I have found is that the binding might be asking for the Gateway version al little too soon.

        03:07:50.895 [DEBUG] [g.mysensors.protocol.MySensorsWriter] - Sending to MySensors: 0;0;3;0;2;
        03:07:50.912 [DEBUG] [g.mysensors.protocol.MySensorsReader] - 0;0;3;0;14;Gateway startup complete.
        03:07:52.644 [ERROR] [s.internal.MySensorsBridgeConnection] - Cannot start reading/writing thread, probably sync message (I_VERSION) not received
        03:07:52.647 [DEBUG] [col.serial.MySensorsSerialConnection] - Shutting down serial connection!
        03:07:52.659 [DEBUG] [g.mysensors.protocol.MySensorsWriter] - Stopping Writer thread
        03:07:52.661 [WARN ] [g.mysensors.protocol.MySensorsWriter] - Writer thread interrupted
        03:07:52.666 [DEBUG] [g.mysensors.protocol.MySensorsReader] - Stopping Reader thread
        

        I have tested this manually and found that the gateway ONLY answers its version after its startup is finished and the message "0;0;3;0;14;Gateway startup complete." is sent.

        When the binding starts, It makes (somehow) the gateway to reboot. So, the gateway runs its setup() method and when it's done, it send the message "0;0;3;0;14;Gateway startup complete"

        Let me know if you can reproduce this error. Maybe it's just some problem with my setup, but with the previus version I was having no issues.

        Regards!

        andreacioniA 1 Reply Last reply
        0
        • G gonzalonal

          Hi @TimO.
          I have just installed the new release and I believe I've found a little bug. I am using Serial Gateway with version 1.5.3

          At boot up time, I am getting the followinf error:

          03:07:52.644 [ERROR] [s.internal.MySensorsBridgeConnection] - Cannot start reading/writing thread, probably sync message (I_VERSION) not received
          

          I have read that this new release, request the gateway for its version so as to prove proper start up.

          What I have found is that the binding might be asking for the Gateway version al little too soon.

          03:07:50.895 [DEBUG] [g.mysensors.protocol.MySensorsWriter] - Sending to MySensors: 0;0;3;0;2;
          03:07:50.912 [DEBUG] [g.mysensors.protocol.MySensorsReader] - 0;0;3;0;14;Gateway startup complete.
          03:07:52.644 [ERROR] [s.internal.MySensorsBridgeConnection] - Cannot start reading/writing thread, probably sync message (I_VERSION) not received
          03:07:52.647 [DEBUG] [col.serial.MySensorsSerialConnection] - Shutting down serial connection!
          03:07:52.659 [DEBUG] [g.mysensors.protocol.MySensorsWriter] - Stopping Writer thread
          03:07:52.661 [WARN ] [g.mysensors.protocol.MySensorsWriter] - Writer thread interrupted
          03:07:52.666 [DEBUG] [g.mysensors.protocol.MySensorsReader] - Stopping Reader thread
          

          I have tested this manually and found that the gateway ONLY answers its version after its startup is finished and the message "0;0;3;0;14;Gateway startup complete." is sent.

          When the binding starts, It makes (somehow) the gateway to reboot. So, the gateway runs its setup() method and when it's done, it send the message "0;0;3;0;14;Gateway startup complete"

          Let me know if you can reproduce this error. Maybe it's just some problem with my setup, but with the previus version I was having no issues.

          Regards!

          andreacioniA Offline
          andreacioniA Offline
          andreacioni
          wrote on last edited by andreacioni
          #134

          @gonzalonal I've implemented the check on startup. On serial gateway with the last version I'm not having any issue, so I would like to know: what hardware are you using? I think that probably is only a timing issue because, for exaple, Arduino UNO reset itself on opening connection and the message for request I_VERSION is sent immediately after connection is opened. I'll suggest you to try adding something like this:

          Thread.sleep(3000)
          

          After line 49 on MySensorsSerialConnection.java. Should become:

          serialConnection = new NRSerialPort(serialPort, baudRate);
                  if (serialConnection.connect()) {
                      logger.debug("Successfully connected to serial port.");
                      Thread.sleep(3000); 
                      mysConReader = new MySensorsSerialReader(serialConnection.getInputStream(), this);
                      mysConWriter = new MySensorsSerialWriter(serialConnection.getOutputStream(), this, sendDelay);
          
                      connected = startReaderWriterThread(mysConReader, mysConWriter);
                  } else {
                      logger.error("Can't connect to serial port. Wrong port?");
                  }
          

          I can't do this test because I do not have an appropriate hardware, can you try the suggested code modification?

          Thanks!

          UPDATE: I've upload a temp build here: https://drive.google.com/file/d/0B11IarucpGdUdFJ2ZjVtZENsb2c/view?usp=sharing if you can't do the modification you can use this. Let me know!

          G 1 Reply Last reply
          0
          • andreacioniA andreacioni

            @gonzalonal I've implemented the check on startup. On serial gateway with the last version I'm not having any issue, so I would like to know: what hardware are you using? I think that probably is only a timing issue because, for exaple, Arduino UNO reset itself on opening connection and the message for request I_VERSION is sent immediately after connection is opened. I'll suggest you to try adding something like this:

            Thread.sleep(3000)
            

            After line 49 on MySensorsSerialConnection.java. Should become:

            serialConnection = new NRSerialPort(serialPort, baudRate);
                    if (serialConnection.connect()) {
                        logger.debug("Successfully connected to serial port.");
                        Thread.sleep(3000); 
                        mysConReader = new MySensorsSerialReader(serialConnection.getInputStream(), this);
                        mysConWriter = new MySensorsSerialWriter(serialConnection.getOutputStream(), this, sendDelay);
            
                        connected = startReaderWriterThread(mysConReader, mysConWriter);
                    } else {
                        logger.error("Can't connect to serial port. Wrong port?");
                    }
            

            I can't do this test because I do not have an appropriate hardware, can you try the suggested code modification?

            Thanks!

            UPDATE: I've upload a temp build here: https://drive.google.com/file/d/0B11IarucpGdUdFJ2ZjVtZENsb2c/view?usp=sharing if you can't do the modification you can use this. Let me know!

            G Offline
            G Offline
            gonzalonal
            wrote on last edited by
            #135

            Hi @andreacioni. Thanks for your answer.
            I have tested your custom build and it's working flawlessly.

            09:10:36.913 [DEBUG] [g.mysensors.protocol.MySensorsReader] - 0;0;3;0;14;Gateway startup complete.
            09:10:37.161 [DEBUG] [g.mysensors.protocol.MySensorsWriter] - Sending to MySensors: 0;0;3;0;2;
            
            09:10:37.172 [DEBUG] [g.mysensors.protocol.MySensorsReader] - 0;0;3;0;2;1.5.3
            09:10:37.177 [DEBUG] [s.internal.MySensorsBridgeConnection] - Good,Gateway is up and running! (Ver:1.5.3)
            

            Let me tell you about my hardware configuration. I am running OH2 Beta2 in a Raspberry Pi 2 Model B with an Arduino Nano V3 working as Serial Gateway directly connected to one of Rpi USB ports.

            Please, let me know if you need me to some tests or maybe is just my config.
            Thanks, regards.

            andreacioniA 1 Reply Last reply
            0
            • G gonzalonal

              Hi @andreacioni. Thanks for your answer.
              I have tested your custom build and it's working flawlessly.

              09:10:36.913 [DEBUG] [g.mysensors.protocol.MySensorsReader] - 0;0;3;0;14;Gateway startup complete.
              09:10:37.161 [DEBUG] [g.mysensors.protocol.MySensorsWriter] - Sending to MySensors: 0;0;3;0;2;
              
              09:10:37.172 [DEBUG] [g.mysensors.protocol.MySensorsReader] - 0;0;3;0;2;1.5.3
              09:10:37.177 [DEBUG] [s.internal.MySensorsBridgeConnection] - Good,Gateway is up and running! (Ver:1.5.3)
              

              Let me tell you about my hardware configuration. I am running OH2 Beta2 in a Raspberry Pi 2 Model B with an Arduino Nano V3 working as Serial Gateway directly connected to one of Rpi USB ports.

              Please, let me know if you need me to some tests or maybe is just my config.
              Thanks, regards.

              andreacioniA Offline
              andreacioniA Offline
              andreacioni
              wrote on last edited by
              #136

              @gonzalonal I've done all of my test on a custom ATMEGA328p shield for BeagleBone Black, running OH2 (beta) so the environment is the same but I've not the reset circuit that gives the issue above. So now I'll push this little fix on the github repo, I think there's nothing to to in this sense. Thank for your time :) !

              If you find some other strange behaviour also remember that github repo has it's own issue tracker available here: https://github.com/tobof/openhab2-addons/issues, it works very well and is the best place to keep track of every software-releated bug :+1:

              Greetings!

              1 Reply Last reply
              1
              • T Offline
                T Offline
                TimO
                Hero Member
                wrote on last edited by TimO
                #137

                There is a new build of the jar available!

                Changes:

                • Added delay before checking the SerialGW (@andreacioni )
                • Requests are answered by the binding (The binding returns "0" if no value was set before)

                https://github.com/tobof/openhab2-addons/issues/8

                G 1 Reply Last reply
                0
                • K Offline
                  K Offline
                  kolaf
                  Hero Member
                  wrote on last edited by
                  #138

                  Are any of you having trouble with this binding together with other bindings that use serial ports? It looks as if the different bindings try to use the same serial port lock, so I get a conflict where things fail til initialize. Think it had something to do with the serial port library...

                  T 1 Reply Last reply
                  0
                  • K kolaf

                    Are any of you having trouble with this binding together with other bindings that use serial ports? It looks as if the different bindings try to use the same serial port lock, so I get a conflict where things fail til initialize. Think it had something to do with the serial port library...

                    T Offline
                    T Offline
                    TimO
                    Hero Member
                    wrote on last edited by
                    #139

                    @kolaf Is it zwave again? Last time I tried to fix the conflict I needed to change the zwave binding.

                    1 Reply Last reply
                    0
                    • K Offline
                      K Offline
                      kolaf
                      Hero Member
                      wrote on last edited by
                      #140

                      It is both zwave and rfxcom. I played about it in the oh2 community some time ago, let me see if I can find a link.

                      1 Reply Last reply
                      0
                      • K Offline
                        K Offline
                        kolaf
                        Hero Member
                        wrote on last edited by
                        #141

                        It is my post: https://community.openhab.org/t/rfxcom-2-0-binding/4427/28?u=frankose

                        1 Reply Last reply
                        0
                        • T TimO

                          There is a new build of the jar available!

                          Changes:

                          • Added delay before checking the SerialGW (@andreacioni )
                          • Requests are answered by the binding (The binding returns "0" if no value was set before)

                          https://github.com/tobof/openhab2-addons/issues/8

                          G Offline
                          G Offline
                          gonzalonal
                          wrote on last edited by gonzalonal
                          #142

                          Hello @TimO .

                          Just tested the last build of the binding. Works great.
                          I see you manage to answer the nodes requests without having to trigger a rule to respond.

                          I though that wasn't possible due to the limitation of the API. Did they manage to solve this from the OH side?

                          Does the binding itself keeps track of the items values, or does it querys OH (or its persistence service) for getting the right value?

                          Thanks!
                          Gonzalo

                          T 1 Reply Last reply
                          0
                          • G gonzalonal

                            Hello @TimO .

                            Just tested the last build of the binding. Works great.
                            I see you manage to answer the nodes requests without having to trigger a rule to respond.

                            I though that wasn't possible due to the limitation of the API. Did they manage to solve this from the OH side?

                            Does the binding itself keeps track of the items values, or does it querys OH (or its persistence service) for getting the right value?

                            Thanks!
                            Gonzalo

                            T Offline
                            T Offline
                            TimO
                            Hero Member
                            wrote on last edited by
                            #143

                            Hi @gonzalonal !

                            I'm glad it works, thanks for testing!
                            Sadly the limitation of the API is still there, but for the implementation of the requestAck feature I needed to implement a memory and now reused this memory to answer requests.

                            There is a really big BUT coming with this implementation: we currently can't use persistence out of the box. For this a rule is needed. After startup of OH we need to use "sendCommand(ITEMNAME, VALUE)", where VALUE Is the value stored in persistance. With that the memory of the binding is filled initially.
                            Hopefully I will find an easier way in the future .

                            G 1 Reply Last reply
                            0
                            • T TimO

                              Hi @gonzalonal !

                              I'm glad it works, thanks for testing!
                              Sadly the limitation of the API is still there, but for the implementation of the requestAck feature I needed to implement a memory and now reused this memory to answer requests.

                              There is a really big BUT coming with this implementation: we currently can't use persistence out of the box. For this a rule is needed. After startup of OH we need to use "sendCommand(ITEMNAME, VALUE)", where VALUE Is the value stored in persistance. With that the memory of the binding is filled initially.
                              Hopefully I will find an easier way in the future .

                              G Offline
                              G Offline
                              gonzalonal
                              wrote on last edited by gonzalonal
                              #144

                              I get what you mean @TimO .

                              Unfortunatelly, using the rule method you suggest would create a lot of traffic (depending on how many sensors you have) at boot up time. Maybe there are some sensors that wouldn't behave the intended way if receiving the "last value" repeteadly.

                              An example. Lets supose I have an automatic gate, that everytime it receives a command, wether its a "1" or "0" it toggles its moving direction. Like the most common automatic gates remotes.

                              Gate is closed.

                              Press button > Gate opens
                              Press button > (if gate moving) Gate stops
                              Press button > (if gate open) Gate closes

                              Now, suppose last command send to the gate made it close. Suddenly, OH restarts itself because of power failure or whatever. It runs the rule to load the memory of the binding, while at the same time it sends to the sensors the last status taken from the persistance service. This would make the gate to open without your notice.

                              This may create dangerous escenarios.
                              I hope you can understand what I mean.

                              Maybe it would be a better idea to handle requests with rules in the way I suggested in the github issue, that is the same way as the OH-1 mysensors serial binding works.

                              Let me know if I can help in any way.
                              Regards.

                              Gonzalo.

                              1 Reply Last reply
                              0
                              • T Offline
                                T Offline
                                TimO
                                Hero Member
                                wrote on last edited by
                                #145

                                @gonzalonal Good point! :worried:

                                If a request (or a message in general) is received there is no "commandReceived" in OH, so you can't trigger a rule based on a message received. So doing it with a rule is not possible.

                                A workaround would be to use "postUpdate()" to update the value after restart. This isn't implemented yet, but is no big deal. This would be a workaround for the workaround, because we still need the rule. :confused:

                                In the OH1 binding the request is answered with the state of the item, as I would like to to do too.
                                Line 277: https://github.com/bloft/openhab/blob/master/bundles/binding/org.openhab.binding.mysensors/src/main/java/org/openhab/binding/mysensors/internal/MySensorsBinding.java

                                G 2 Replies Last reply
                                0
                                • T TimO

                                  @gonzalonal Good point! :worried:

                                  If a request (or a message in general) is received there is no "commandReceived" in OH, so you can't trigger a rule based on a message received. So doing it with a rule is not possible.

                                  A workaround would be to use "postUpdate()" to update the value after restart. This isn't implemented yet, but is no big deal. This would be a workaround for the workaround, because we still need the rule. :confused:

                                  In the OH1 binding the request is answered with the state of the item, as I would like to to do too.
                                  Line 277: https://github.com/bloft/openhab/blob/master/bundles/binding/org.openhab.binding.mysensors/src/main/java/org/openhab/binding/mysensors/internal/MySensorsBinding.java

                                  G Offline
                                  G Offline
                                  gonzalonal
                                  wrote on last edited by gonzalonal
                                  #146

                                  Hi @TimO . Good we got in the same page.

                                  I think this topic needs some more thinking.

                                  I was reading OH wiki and found this about receivedCommand.

                                  
                                   Implicit Variables inside the Execution Block
                                  
                                  Besides the implicitly available variables for items and commands/states (see the script documentation), rules can have additional pre-defined variables, depending on their triggers:
                                  
                                  
                                  * Every rule that has at least one command event trigger, will have the variable 
                                  receivedCommand available, which can be used inside the execution block.
                                  
                                  * Every rule that has at least one status change event trigger, will have the variable
                                  previousState available, which can be used inside the execution block.
                                  

                                  https://github.com/openhab/openhab/wiki/Rules

                                  Maybe this is not available anymore, or at least on OH2.

                                  For now, I think it would be a better approach to use postUpdate at systemStart to populate the binding memory. With this, we'll avoid sending commands to the nodes.

                                  Regards!

                                  1 Reply Last reply
                                  0
                                  • T TimO

                                    @gonzalonal Good point! :worried:

                                    If a request (or a message in general) is received there is no "commandReceived" in OH, so you can't trigger a rule based on a message received. So doing it with a rule is not possible.

                                    A workaround would be to use "postUpdate()" to update the value after restart. This isn't implemented yet, but is no big deal. This would be a workaround for the workaround, because we still need the rule. :confused:

                                    In the OH1 binding the request is answered with the state of the item, as I would like to to do too.
                                    Line 277: https://github.com/bloft/openhab/blob/master/bundles/binding/org.openhab.binding.mysensors/src/main/java/org/openhab/binding/mysensors/internal/MySensorsBinding.java

                                    G Offline
                                    G Offline
                                    gonzalonal
                                    wrote on last edited by gonzalonal
                                    #147

                                    Hi again @TimO .

                                    Just an idea.

                                    What do you think about solving this problematic in this way:

                                    We create a group whose members are all those items that later will populate the binding's memory. I have a group named mysqlpersisted where I put all the items whose data will be stored in my SQL DB. So I could use that group. For this example, let's call it "MemoryGroup"

                                    Then, we can create the following rule:

                                    rule "Populate MySensors binding memory"
                                    
                                    when 
                                    System started
                                    then
                                    
                                    (maybe add a delay to allow persistance services to load)
                                    
                                    MemoryGroup?.members.forEach[i |
                                            postUpdate(i.name, i.previousState(true))
                                    ]
                                    

                                    Using this method, memory would get populated everytime OH boots up, with data belonging to the persistance service that we use. And we use postUpdate, so no command is sent to the nodes.

                                    With this I think we solve both problems as data in the binding will be concurrent with the persistance service data.

                                    Let me know what you think about this.

                                    Regards!

                                    1 Reply Last reply
                                    1
                                    • T Offline
                                      T Offline
                                      TimO
                                      Hero Member
                                      wrote on last edited by
                                      #148

                                      Hi @gonzalonal !

                                      I was thinking in the same direction and I have played a litte bit with different rules. I had no success in finding a rule that worked. Additionally I don't like the workaround. ;-)

                                      A good solution would be, to trigger a rule, if a request is received, but there too I had no success till now.

                                      I'm still struggling with it ...

                                      1 Reply Last reply
                                      0
                                      • T Offline
                                        T Offline
                                        tomkxy
                                        wrote on last edited by
                                        #149

                                        @TimO Do you think it would be hard to add MQTT support to the binding? I had a brief look to your code and it looks like the protocols are nicely isolated.

                                        1 Reply Last reply
                                        0
                                        • T Offline
                                          T Offline
                                          TimO
                                          Hero Member
                                          wrote on last edited by
                                          #150

                                          I'm currently trying to migrate my production environment from OH1 to OH2. I'm now using two serial gateways.

                                          @kolaf : The problem you described occured to me too. In my case I use two serial gateways. I've added a little method that ensures that a connection to more than two serial ports via nrjavaserial is possible. It works within the OH2 binding. Could you test if it works with the RFXCOM binding you are using? A new jar is available on github. OH2 is currently using an old version of nrserialjava that has a bug. I don't know how to switch the version yet.

                                          @tomkxy : I will integrate MQTT in my OH2 Installation soon and will come back to your request after that.

                                          K 1 Reply Last reply
                                          0
                                          Reply
                                          • Reply as topic
                                          Log in to reply
                                          • Oldest to Newest
                                          • Newest to Oldest
                                          • Most Votes


                                          20

                                          Online

                                          11.7k

                                          Users

                                          11.2k

                                          Topics

                                          113.0k

                                          Posts


                                          Copyright 2019 TBD   |   Forum Guidelines   |   Privacy Policy   |   Terms of Service
                                          • Login

                                          • Don't have an account? Register

                                          • Login or register to search.
                                          • First post
                                            Last post
                                          0
                                          • MySensors
                                          • OpenHardware.io
                                          • Categories
                                          • Recent
                                          • Tags
                                          • Popular