Navigation

    • Register
    • Login
    • OpenHardware.io
    • Categories
    • Recent
    • Tags
    • Popular
    1. Home
    2. marcusvdt
    • Profile
    • Following
    • Followers
    • Topics
    • Posts
    • Best
    • Groups

    marcusvdt

    @marcusvdt

    2
    Reputation
    20
    Posts
    671
    Profile views
    0
    Followers
    0
    Following
    Joined Last Online

    marcusvdt Follow

    Best posts made by marcusvdt

    • How to deal with a request for information from controller?

      I'm building some sensors and planning to use a self build controller in the future. For the meantime, I'm sending commands from my computer through a serial terminal to the gateway which them forwards these commands to the nodes.
      I'm trying to figure out how to make the node respond to a req message from the controller and to send the acks as requested.

      This is what I'm sending from the controller:
      51;99;2;1;2;\n
      Which to me, means:
      node id: 51
      child id:99
      message type: 2 (req)
      ack: 1 (request ack)
      sub type: 1 (V_LIGHT)
      payload: none

      The purpose of this message is to get the current status of a light actuator. I need this because this light actuator has a button to control the lights. My sketch does inform the gateway when I switch the light on/off through the button attached to the node, but I want to deal with the case where the communication may have failed between the node and the gateway at the time the button has been used to control the lights. This situation could be the controller is down for some reason, there is something interfering with the radio comms, etc.

      Well, I suppose I need to deal with the ack response and the req response in my sketch. Am I right?
      If so, I'm looking for examples on how to differentiate between a message that is sent from the controller to the node (obviously through the gateway) to either change the light status OR to request the current light status. I know the sub-type of the message would change from 1 to 2 respectively, but I don't know what is the way to read this value from the incoming messages.
      The other thing I'm looking for, is if the ack response is automatically generated and sent from the controller, and if not, how do I read an ack incoming message and how do I respond to it. A simple function example is well enough.

      Please correct me if I'm wrong in any of my previous statements.

      Thanks!

      posted in Troubleshooting
      marcusvdt
      marcusvdt
    • RE: How to deal with a request for information from controller?

      Well, it seems nobody has either the motivation or the answer itself... Wonder if I should have posted this question in the Development forum instead...
      I've been researching and doing some trial and error since I posted the question, and it seems I found a way of doing it. Not sure if this is the correct way because I just did not find any documentation about it, but I'll share my discoveries anyway since it can help others.

      It seems the ack part is done automatically by the library itself. I've been able to see ack messages returning from the gateway to the controller without doing any treatment myself in my sketch.

      Regarding how to differentiate "req" messages sent from the controller to a node, I've been able to detect if a message is a "req" one by reading the value of mGetCommand(message) in my sketch. If this is equal to 2, then it is a "req" message, if it is equal to 1, then it is a "set" message.

      void incomingMessage(const MyMessage &message) {
      //debug only
      //Serial.print("message.destination=");
      //Serial.println(message.destination);
      //Serial.print("message.type=");
      //Serial.println(message.type);
      //Serial.print("message.sensor");
      //Serial.println(message.sensor);
      
      int comando = mGetCommand(message);
      //Serial.print("comando=");
      //Serial.println(comando);
      
        if (message.type==V_LIGHT) {
          //comando=2 means information has been requested from controller, so we will send it back.
          //comando=1 means a new status has been received from controller to the node, so we will act as requested.
          if (comando==2){
            gw.send(lightMsg.set(digitalRead(lightPin)));
          }
          if (comando==1){
            // Change relay state
            setLightState(message.getBool(), false); 
            // Write some debug info
            Serial.print("Incoming light status:");
            Serial.println(message.getBool());
          }
         }
        if (message.type==V_VAR1) {
          // Toggle program mode
          if (programModeActive == false){     // If we're not in programming mode, turn it on.
            programmingmode(1);
          } else {                             // If we are in programing mode, turn it off.
            programmingmode(0);
          } 
          // Write some debug info
          Serial.print("Toggled program mode:");
          Serial.println(message.getBool()); 
        }
      }
      

      And below are the tests that show what I mentioned.

      Sent this, which sets the light child 99 on node 51 to 1 (on), requesting an ack
      51;99;1;1;2;1

      0;0;3;0;14;Gateway startup complete.
      0;0;3;0;9;send: 0-0-51-51 s=99,c=1,t=2,pt=0,l=1,st=ok:1
      0;0;3;0;9;read: 51-51-0 s=99,c=1,t=2,pt=0,l=1:1
      51;99;1;1;2;1
      

      The last one is the ack itself that returned from the gateway to the controller.

      Then sent this, which requests the status of light child 99 on node 51, requesting an ack. Should return the ack and the response containing the current status of the light (1).
      51;99;2;1;2;anything

      0;0;3;0;9;send: 0-0-51-51 s=99,c=2,t=2,pt=0,l=8,st=ok:anything
      0;0;3;0;9;read: 51-51-0 s=99,c=2,t=2,pt=0,l=8:anything
      51;99;2;1;2;anything
      0;0;3;0;9;read: 51-51-0 s=99,c=1,t=2,pt=2,l=2:1
      51;99;1;0;2;1
      

      This "51;99;2;1;2;anything" is the ack generated automatically by the library, and this "51;99;1;0;2;1" is the response that my program performs. Correct!

      Then sent this, which sets the light child 99 on node 51 to 0 (off), requesting an ack
      51;99;1;1;2;0

      0;0;3;0;9;send: 0-0-51-51 s=99,c=1,t=2,pt=0,l=1,st=ok:0
      0;0;3;0;9;read: 51-51-0 s=99,c=1,t=2,pt=0,l=1:0
      51;99;1;1;2;0
      

      The last one above is the ack generated automatically by the library.

      Then sent this, which requests the status of light child 99 on node 51, requesting an ack. Should return the ack and the response containing the current status of the light (0).
      51;99;2;1;2;anything

      0;0;3;0;9;send: 0-0-51-51 s=99,c=2,t=2,pt=0,l=8,st=ok:anything
      0;0;3;0;9;read: 51-51-0 s=99,c=2,t=2,pt=0,l=8:anything
      51;99;2;1;2;anything
      0;0;3;0;9;read: 51-51-0 s=99,c=1,t=2,pt=2,l=2:0
      51;99;1;0;2;0
      

      This "51;99;2;1;2;anything" is the ack generated automatically by the library, and this "51;99;1;0;2;0" is the response that my program performs. Correct!

      posted in Troubleshooting
      marcusvdt
      marcusvdt

    Latest posts made by marcusvdt

    • RE: How to deal with a request for information from controller?

      @barduino
      I'll post it for you tomorrow, but my main concern is to keep the things as much as possible conform the design of this protocol. It's because I don't want that my future version upgrades turn into a nightmare.
      That's why I wanted someone from mysensors staff to tell me about this.

      IMHO, there are many legitimate reasons for a controller needing to request information to sensors.
      In my case, I have light actuators that I designed to work either from a standard wall switch or by commands sent from the controller or by claps. I find the need to request information from the actuator node because sometimes the computer where the controller is running could be unreachable. Also some times the radio can fail. And sometimes I could just want to make sure the current status shown on my controller matches the current status of the actual node. Also, like you said, this allows node to request information from other nodes.

      posted in Troubleshooting
      marcusvdt
      marcusvdt
    • RE: How to deal with a request for information from controller?

      @hek
      I have solved this by implementing a response for messages of type=2 on every sensor that I build, in addition to the processing for type=1 that is already included in the examples. Could you please confirm if this is supported or designed to work like this?
      I'm using my own custom controller that has support to send messages of type=2 (type=request) and it does process the responses from the nodes correctly, because the responses from the nodes are just normal set messages (type=1).

      posted in Troubleshooting
      marcusvdt
      marcusvdt
    • RE: Doubts about sensor types versus variable types

      @hek [quote]The main reason for the current variable-types has a Vera-controller legacy. It is simply 1-1 mapping to their devices/variables.[/quote]
      I was knocking my head to the wall to understand why you guys have done this that way.
      What I'm doing on my controller is to create database tables that will group and relate those variable types to what should be displayed on the user interface.

      Thanks for the help.
      I think I can go ahead, but some sensor types are still not clear to me.

      @Heinz
      This is what I thought since I started looking at this stuff.

      posted in Controllers
      marcusvdt
      marcusvdt
    • RE: Doubts about sensor types versus variable types

      Thanks, it helps a lot!
      But I still wanted to have a clear definition of some of the variable types.
      The major concern is, if V_LIGHT is supposed to read a binary value of 0 or 1, then my controller should support it correctly. I'm using it this way, but then I saw in the comments from the link you just sent this:
      V_LIGHT, // S_LIGHT (Light level in uncalibrated percentage)

      This conflicts with what is posted on the variable types page:
      V_LIGHT Light status. 0=off 1=on

      I'm supposing there is no such documentation yet, or the subject is not cleared defined in the API. That's ok if not, I know you guys give your best and I'm very grateful for having this stuff available for free. I mean, I'm not complaining.
      I just want to make sure I'm developing a controller which conforms with the standard API, hence the need to clarify this. If the controller is supposed to read a binary value for V_LIGHT, then it will be programmed for that. If it is supposed to read a percentage, the same.

      Can you guys help me? Maybe if I post a table with my guesses for each variable type, you can confirm/correct?

      posted in Controllers
      marcusvdt
      marcusvdt
    • Doubts about sensor types versus variable types

      I'm building a self made controller in python that will integrate in another automation software. It's like a plugin for such software.

      It is working already but I'm now looking for enhancing the controller and have it conforming to standard MySensors protocol so it can be easily updated when new versions of the API are released.

      Regarding sensor types, I'm assuming they exist so each sensor type can have one or more variable types related to it. As mentioned in the API page, power meters could report both the accumulated KWH and the current WATTAGE. Hence the controller should be able to know how it will show the received information for the user by looking on the variable type reported by the sensor.
      So, a S_LIGHT sensor will have the variable type V_LIGHT assigned to it, which means it can receive light status 0=off or 1=on, and whatever these values are received or sent to/from a node, for the end user these values should be displayed simply as ON or OFF.

      If I'm correct above, I'd like to build a table of what specific data types are expected for each of various types of variables documented on the API.
      For example, for the S_RAIN sensor, I suppose it expects both the V_RAIN and the V_RAINRATE values, but as for the controller side, how is it supposed to deal with each value? Is the V_RAIN a float number? In which unity of measure should it be displayed for the user? Is the V_RAINRATE a float number? Is it a percentage value?

      I also would like to know if there is a list somewhere relating the sensor types with each variable type they are supposed to be related to. Something like:
      S_LIGHT = V_LIGHT
      S_RAIN = V_RAIN, V_RAINRATE
      etc

      Then I would have another table relating each variable type with the type of data it is, something like:

      Variable valid values table
      data_types	|	Valid_value	|	Setting		|	Display
      ============|===============|===============|==================
      V_LIGHT		|	0			|	OFF			|	turned on
      V_LIGHT		|	1			|	ON			|	turned off
      V_RAIN		|	FLOAT		|	Not appl.	|	inches
      
      posted in Controllers
      marcusvdt
      marcusvdt
    • RE: How to deal with a request for information from controller?

      Yes, I have done it already. Now I need to migrate all enhancements from my "Secret Clap Lights" sketch to the RGB controller sketch developed by Dave. I will share it with you guys once it is done. I'm now working on some enhancements on the Vox Commando part. Not sure yet if all of my ideas will work, but they look promising.

      I'm working to get Vox Commando to be smarter when working with My Sensors.
      The idea consists of making it know in advance what commands make sense for each type of sensor/actuator. Different values will be accepted as phrases and payloads for different devices automatically. No need to create a new command for every new standard sensor that you add to your network.
      It is a hard job it seems, but I think it is possible.

      Thanks!

      posted in Troubleshooting
      marcusvdt
      marcusvdt
    • RE: How to deal with a request for information from controller?

      Thanks Kalle!
      But this part I was already aware. My doubt is how I could achieve the same on the node, meaning the sketch itself should be able to respond to a request from the controller (not the opposite as you showed above). I other words, my doubt was: how would the node respond for a request for current status of such node.

      This is also not implemented in the RGB sketch written by Dave, hence all the queries for status return values from the map tables, not the actual node. I'm going to implement the capacity of being queried on the RGB sketch, together with other small changes. The idea is that the node can be queried for current status at anytime because after this mod it will not be controlled exclusively by Vox Commando, but I will be able to control it also by claps and a wall switch.

      I've found the solution for this specific thread anyway, and as I showed in my previous post, it is working like a charm now!

      Good to hear from ya! Thanks!

      posted in Troubleshooting
      marcusvdt
      marcusvdt
    • RE: How to deal with a request for information from controller?

      Well, it seems nobody has either the motivation or the answer itself... Wonder if I should have posted this question in the Development forum instead...
      I've been researching and doing some trial and error since I posted the question, and it seems I found a way of doing it. Not sure if this is the correct way because I just did not find any documentation about it, but I'll share my discoveries anyway since it can help others.

      It seems the ack part is done automatically by the library itself. I've been able to see ack messages returning from the gateway to the controller without doing any treatment myself in my sketch.

      Regarding how to differentiate "req" messages sent from the controller to a node, I've been able to detect if a message is a "req" one by reading the value of mGetCommand(message) in my sketch. If this is equal to 2, then it is a "req" message, if it is equal to 1, then it is a "set" message.

      void incomingMessage(const MyMessage &message) {
      //debug only
      //Serial.print("message.destination=");
      //Serial.println(message.destination);
      //Serial.print("message.type=");
      //Serial.println(message.type);
      //Serial.print("message.sensor");
      //Serial.println(message.sensor);
      
      int comando = mGetCommand(message);
      //Serial.print("comando=");
      //Serial.println(comando);
      
        if (message.type==V_LIGHT) {
          //comando=2 means information has been requested from controller, so we will send it back.
          //comando=1 means a new status has been received from controller to the node, so we will act as requested.
          if (comando==2){
            gw.send(lightMsg.set(digitalRead(lightPin)));
          }
          if (comando==1){
            // Change relay state
            setLightState(message.getBool(), false); 
            // Write some debug info
            Serial.print("Incoming light status:");
            Serial.println(message.getBool());
          }
         }
        if (message.type==V_VAR1) {
          // Toggle program mode
          if (programModeActive == false){     // If we're not in programming mode, turn it on.
            programmingmode(1);
          } else {                             // If we are in programing mode, turn it off.
            programmingmode(0);
          } 
          // Write some debug info
          Serial.print("Toggled program mode:");
          Serial.println(message.getBool()); 
        }
      }
      

      And below are the tests that show what I mentioned.

      Sent this, which sets the light child 99 on node 51 to 1 (on), requesting an ack
      51;99;1;1;2;1

      0;0;3;0;14;Gateway startup complete.
      0;0;3;0;9;send: 0-0-51-51 s=99,c=1,t=2,pt=0,l=1,st=ok:1
      0;0;3;0;9;read: 51-51-0 s=99,c=1,t=2,pt=0,l=1:1
      51;99;1;1;2;1
      

      The last one is the ack itself that returned from the gateway to the controller.

      Then sent this, which requests the status of light child 99 on node 51, requesting an ack. Should return the ack and the response containing the current status of the light (1).
      51;99;2;1;2;anything

      0;0;3;0;9;send: 0-0-51-51 s=99,c=2,t=2,pt=0,l=8,st=ok:anything
      0;0;3;0;9;read: 51-51-0 s=99,c=2,t=2,pt=0,l=8:anything
      51;99;2;1;2;anything
      0;0;3;0;9;read: 51-51-0 s=99,c=1,t=2,pt=2,l=2:1
      51;99;1;0;2;1
      

      This "51;99;2;1;2;anything" is the ack generated automatically by the library, and this "51;99;1;0;2;1" is the response that my program performs. Correct!

      Then sent this, which sets the light child 99 on node 51 to 0 (off), requesting an ack
      51;99;1;1;2;0

      0;0;3;0;9;send: 0-0-51-51 s=99,c=1,t=2,pt=0,l=1,st=ok:0
      0;0;3;0;9;read: 51-51-0 s=99,c=1,t=2,pt=0,l=1:0
      51;99;1;1;2;0
      

      The last one above is the ack generated automatically by the library.

      Then sent this, which requests the status of light child 99 on node 51, requesting an ack. Should return the ack and the response containing the current status of the light (0).
      51;99;2;1;2;anything

      0;0;3;0;9;send: 0-0-51-51 s=99,c=2,t=2,pt=0,l=8,st=ok:anything
      0;0;3;0;9;read: 51-51-0 s=99,c=2,t=2,pt=0,l=8:anything
      51;99;2;1;2;anything
      0;0;3;0;9;read: 51-51-0 s=99,c=1,t=2,pt=2,l=2:0
      51;99;1;0;2;0
      

      This "51;99;2;1;2;anything" is the ack generated automatically by the library, and this "51;99;1;0;2;0" is the response that my program performs. Correct!

      posted in Troubleshooting
      marcusvdt
      marcusvdt
    • How to deal with a request for information from controller?

      I'm building some sensors and planning to use a self build controller in the future. For the meantime, I'm sending commands from my computer through a serial terminal to the gateway which them forwards these commands to the nodes.
      I'm trying to figure out how to make the node respond to a req message from the controller and to send the acks as requested.

      This is what I'm sending from the controller:
      51;99;2;1;2;\n
      Which to me, means:
      node id: 51
      child id:99
      message type: 2 (req)
      ack: 1 (request ack)
      sub type: 1 (V_LIGHT)
      payload: none

      The purpose of this message is to get the current status of a light actuator. I need this because this light actuator has a button to control the lights. My sketch does inform the gateway when I switch the light on/off through the button attached to the node, but I want to deal with the case where the communication may have failed between the node and the gateway at the time the button has been used to control the lights. This situation could be the controller is down for some reason, there is something interfering with the radio comms, etc.

      Well, I suppose I need to deal with the ack response and the req response in my sketch. Am I right?
      If so, I'm looking for examples on how to differentiate between a message that is sent from the controller to the node (obviously through the gateway) to either change the light status OR to request the current light status. I know the sub-type of the message would change from 1 to 2 respectively, but I don't know what is the way to read this value from the incoming messages.
      The other thing I'm looking for, is if the ack response is automatically generated and sent from the controller, and if not, how do I read an ack incoming message and how do I respond to it. A simple function example is well enough.

      Please correct me if I'm wrong in any of my previous statements.

      Thanks!

      posted in Troubleshooting
      marcusvdt
      marcusvdt
    • RE: Eeprom usage

      @hek I have a quick question regarding the gw.saveState and consequently the gw.loadState instructions
      As per the link and code you have mentioned, reproduced below:

      // EEPROM start address for mysensors library data
      #define EEPROM_START 0
      // EEPROM location of node id
      #define EEPROM_NODE_ID_ADDRESS EEPROM_START
      // EEPROM location of parent id
      #define EEPROM_PARENT_NODE_ID_ADDRESS (EEPROM_START+1)
      // EEPROM location of distance to gateway
      #define EEPROM_DISTANCE_ADDRESS (EEPROM_PARENT_NODE_ID_ADDRESS+1)
      #define EEPROM_ROUTES_ADDRESS (EEPROM_DISTANCE_ADDRESS+1) // Where to start storing routing information in EEPROM. Will allocate 256 bytes.
      #define EEPROM_CONTROLLER_CONFIG_ADDRESS (EEPROM_ROUTES_ADDRESS+256) // Location of controller sent configuration (we allow one payload of config data from controller)
      #define EEPROM_FIRMWARE_TYPE_ADDRESS (EEPROM_CONTROLLER_CONFIG_ADDRESS+24)
      #define EEPROM_FIRMWARE_VERSION_ADDRESS (EEPROM_FIRMWARE_TYPE_ADDRESS+2)
      #define EEPROM_FIRMWARE_BLOCKS_ADDRESS (EEPROM_FIRMWARE_VERSION_ADDRESS+2)
      #define EEPROM_FIRMWARE_CRC_ADDRESS (EEPROM_FIRMWARE_BLOCKS_ADDRESS+2)
      #define EEPROM_LOCAL_CONFIG_ADDRESS (EEPROM_FIRMWARE_CRC_ADDRESS+2) // First free address for sketch static configuration
      

      I understand it translates to:

      ADDRESS	SIZE		ALIAS
      0X000	1 BYTE		EEPROM_START, EEPROM_NODE_ID_ADDRESS
      0X001	1 BYTE		EEPROM_PARENT_NODE_ID_ADDRESS
      0X002	1 BYTE		EEPROM_DISTANCE_ADDRESS
      0X003	256 BYTES		EEPROM_ROUTES_ADDRESS
      0X103	24 BYTES	EEPROM_CONTROLLER_CONFIG_ADDRESS
      0X11B	2 BYTES		EEPROM_FIRMWARE_TYPE_ADDRESS
      0X11D	2 BYTES		EEPROM_FIRMWARE_VERSION_ADDRESS
      0X11F	2 BYTES		EEPROM_FIRMWARE_BLOCKS_ADDRESS
      0X121	2 BYTES		EEPROM_FIRMWARE_CRC_ADDRESS
      0X123	???			EEPROM_LOCAL_CONFIG_ADDRESS
      

      So it means when I perform these instructions:
      lightStatus = state;
      gw.saveState(0,state);

      In what specific address am I saving the data? The instruction itself says position zero, so am I saving to the first address 0x123 in this case???

      Thanks in advance.

      posted in General Discussion
      marcusvdt
      marcusvdt