Hi there,

I am currently busy designing a MySensors API. This project is named OhMySensors and is available at https://github.com/marvinroger/OhMySensors. Don't mind the front-end code yet.

This is basically a node.js application acting as a controller, and as a storage layer for the data sent by the sensors. All the data is available through a WebSocket API, documented on the Wiki.

Do you think the API is well designed? Would you change something? If there are some front-end devs around here, would it be easy for you to build a front-end based on this API?

Thanks for your feedbacks.

Hi there,

I am currently busy designing a MySensors API. This project is named OhMySensors and is available at https://github.com/marvinroger/OhMySensors. Don't mind the front-end code yet.

This is basically a node.js application acting as a controller, and as a storage layer for the data sent by the sensors. All the data is available through a WebSocket API, documented on the Wiki.

Do you think the API is well designed? Would you change something? If there are some front-end devs around here, would it be easy for you to build a front-end based on this API?

Thanks for your feedbacks.

@AWI I did think about this, but don't you think this is a bit too much, sending, in case of shutters for example, each percentage reached? That's a lot of overhead, and it might be error-prone (if the user requests 100% and if the last message that sets the GUI to 100% fails somehow, the user will see 99% — but the shutters will actually be 100% —).

This is an interesting problematic as it is, in my opinion, essential that the sensors have a consistent behavior.

I don't want to create another topic as the subject is almost the same. I'm building a controller and ack is something important. For the GUI of the controller to work correctly, sensors need to follow standards. In case of an actuator, I thought the standard would only be to wait for an ack to update the GUI. But if you look at the Dimmer code, it also sends back its state (on/off, and %). So this is a double ack or something... Moreover, it's pretty obvious that when the percentage set is > 0%, the light is on (in the context of the sketch). Is there any kind of best practices guide somewhere?

Great, and as I see it waits two seconds waiting for the configuration reply. So when you enter in the loop, you're quite sure everything is set! Thanks.

No, it would be a workaround, not a real solution.
I know what happens... It's 30°C where I am, which is about 85°F. Well, the first value I received was 85.0, a value that I thought was the Fahrenheit one, but it is not. It appears that +85.0°C is the power-on reset value of the temperature register... which is ignored in the official temp sketch since 17 June, I didn't see.

So there is no problem finally!

Hey,

I just started to create a MySensors controller, and I face a problem relating the metric/imperial config, using this sketch:

#include <SPI.h>
#include <EEPROM.h>
#include <MySensor.h>
#include <DallasTemperature.h>
#include <OneWire.h>

#define TEMPERATURE_ID 1

#define ONE_WIRE_BUS 4
#define TEMPERATURE_INTERVAL 120

OneWire oneWire(ONE_WIRE_BUS);
DallasTemperature temperatureSensors(&oneWire);
MySensor gw;
MyMessage msgTemperature(TEMPERATURE_ID, V_TEMP);

unsigned long time_temperature_sent;

void setup() {
  temperatureSensors.begin();
  gw.begin(handleMessage);
  gw.sendSketchInfo("Temperature", "0.1");
  gw.present(TEMPERATURE_ID, S_TEMP, "Room temperature");
}

void loop() {
  gw.process();
  if (millis() - time_temperature_sent >= TEMPERATURE_INTERVAL * 1000UL) {
    temperatureSensors.requestTemperaturesByIndex(0); 
    float temperature = static_cast<float>(static_cast<int>((gw.getConfig().isMetric?temperatureSensors.getTempCByIndex(0):temperatureSensors.getTempFByIndex(0)) * 10.)) / 10.;
    gw.send(msgTemperature.set(temperature, 1));
    time_temperature_sent = millis();
  }
}

void handleMessage(const MyMessage& receivedMessage) {
}

Once the controller receives the I_CONFIG message, it replies with a M to indicate we want a value in Celcius. I am an hundred percent sure the reply is received by the sensor.
The first value is sent after two minutes, so the sensor has received and processed the I_CONFIG before sending out its first value.

But the fact is the first value sent is in Fahrenheit, and then all subsequent values sent are in Celcius. It's like if the isMetric is not updated, even after having received the config from the controller, until the first send. This happens after each reboot of the sensor.
Maybe I am missing something?

Thanks for your answers.