Posts made by nneeoo

There are example gateways for Raspberry Pi in the MySensors Raspberry repo on github. You can easily modify e.g. the serial gateway and instead of creating pseudo terminal you would create a network socket and write/read data to/from the socket.

If anyone is interested in trying out the implementation using UDP packets sent to the subnet broadcast address, check out my pull request https://github.com/mysensors/Arduino/pull/66

@Zen
Multicast and broadcast are two different things. You can broadcast a packet by sending it to a broadcast IP address of the network you are on.

So if you are on network 192.168.1.0/24, the broadcast address will be 192.168.1.255. Then the controller listening on a socket with IP address from that network should get it.

I think it can be achieved by simply sending a special (new) internal message from GW to the broadcast IP address using UDP (we should use some specific port all the time). The Controller will get it and respond to with the same type of internal message that can contain its IP address (or GW can extract the IP from response).

The first step from my point of view is adding a new internal message type. I will try out my ideas during the weekend and if working create a pull request on Github. I wanted to get some feedback, since I think it might be an interesting Feature, rather than hard-coding everything into GW.

Hi.

I have been working with Ethernet Gateway and modified it to obtain IP address using DHCP. I would also like the Controller to run with dynamically assigned address. I was thinking it might be a nice feature, to enhance the MySensors protocol (the internal msg) section to be able to broadcast a "controller discovery" packet and let the controller reply with its IP address.

My idea is that the GW may have some controller IP hard-coded, but in the setup() it will try to find a controller using the discovery. The discovery could be also triggered by some button later.

What do you think?

Hi. I just used MySensors library with the iBoard without any HW modifications. All You have to do is to edit utils/RF24_config.h.

uncomment the following line:

#define SOFTSPI   // Requires library from https://github.com/greiman/DigitalIO

and modify SOFT SPI PIN definitions to

const uint8_t SOFT_SPI_MISO_PIN = 6; 
const uint8_t SOFT_SPI_MOSI_PIN = 5; 
const uint8_t SOFT_SPI_SCK_PIN = 7;

And it all "just works" Of course you have to have the DigitalIO library, too.

@BulldogLowell said:

@nneeoo

Oh, you are requesting the duration of the sleep... not the moment at which you wish it to sleep.

I thought you were wanting it to transmit data at certain times...

Well, yes. I want the node to transmit at certain time. Since the controller should know when that time is, it has to be able to calculate for how long should the node sleep, when the node asks the controller. I hope you get my point.

@BulldogLowell said:

Right now you can use the Time.h library and you don't need an RTC.

Just sync the time with MySensors call...

gw.requestTime(receiveTime);

with the function:

void receiveTime(unsigned long controllerTime) 
{
  Serial.print("Time value received: ");
  Serial.println(controllerTime);
  RTC.set(controllerTime);
}

Thanks for pointing out this library. However I don't want to track the time on the node, but would like just request the time for which the node should sleep from the controller. I think it makes more sense to have the logic in controller.

@hek said:

You can use VAR1-5 for this in 1.4.

2.0 will have both VAR (used mostly for pushing custom data) and CONFIG (for custom node configuration).

Yeah, good point. I somehow missed these general purpose variables. It might be good to add a dedicated type for it if you'll find it useful. If not I can live with the VAR for sure ;). Thanks.

Hi. I would like my nodes measuring various values (temperature, humidity, ...) to send those values at specific times. I don't want to include the RTC on the node, so would like the node to request a sleep period from the controller. I can see there is no such possibility with the version 1.4 of the protocol. What do you think about including such thing?