Esp8266gateway with direct rest-api access to pimatic

[Harry van der Wolf]

Esp8266GatewayPimatic

This mysensors EspGateway2866 pushes sensor values directly to Pimatic via the REST-API.
You find it in my Esp8266GatewayPimatic repository. It currently only reads sensor values. It does not write sensor values back into the network. It is of course very limited compared to the GatewayESP8266MQTTClient but it is an extremely simple implementation not needing any plugins.

It is based on this post in the mysensors forum leading to this repository.

I combined a few things, stole a few things left and right (can't remember where; honestly) and came up with this new ino.

I included a Base64 library which is not be default included in the arduino package and which is definitely not the same as the base64 library inside the arduino library (note the Base64 vs. the base64). You need to copy this library into the libraries folder of your arduino setup, not in the mysensors setup.

Currently this ino receives sensor values from the mysensors network and pushes them as variables with their value to pimatic. Say you have a temperature sensor as node 2 child 0 with (temp) value 21.6. The variable pushed to pimatic will be "2-0", the value will of course be "21.6".

It is done in a mysensors 1.5 format as I have no idea how to do it in mysensors 2.0 format.
The default branch of my repository contains the mysensors 2.0 version. The other branch contains the previous mysensors 1.5 version.

The devices and variables section is identical to Esp8266gateway and pymysensors: another option/workaround

I also posted the pimatic extension to pymysensors thread but that was because I had not found the above mentioned thingspeak post at that time. I will not continue on that pymysensors one.

[Harry van der Wolf]

As mentioned in the 2nd paragraph of the above first post: this spin-off for pimatic was based on a post of lendog.
lendog thanks @Hek, @Yveaux, and @nikil511 , so in hist post I do the same

And at the same time I ask assistance: "my" version for pimatic is also based on the 1.5 mysensors syntax and is based on a modified gw.begin. That has now disappeared. I'm a relatively experienced "code copier" but I'm stuck now.

2 questions:

• How do I convert this ino to 2.0 format (hopefully without needing to modify/patch the core mysensors code)
• When converting to 2.0 format: Will it also immediately solve the "2byte arduino int" to "4byte esp8266 int" issue or do I have to write a "strip 2 highest bytes" function to solve this. I can do that but is it already "automatically" solved? (I thought by Yveaux but can't find it)

[Yveaux]

@Harry-van-der-Wolf The integer problem was fixed in development branch, so you should be good.
Without the actual 1.5 code it's hard to explain what should be modified for 2.0.
The examples directory in development is up-to-date (copy away ;-)) so maybe that will point you in the right direction.

[Harry van der Wolf]

Hi,

Thanks for your fast response.
My code is in my github repo.
But actually it is this part of modified code in the void setup() which was in the 1.5 version:

  setupGateway(INCLUSION_MODE_PIN, INCLUSION_MODE_TIME, output);

  // Initialize gateway at maximum PA level, channel 70 and callback for write operations 
  //gw.begin(incomingMessage, 0, true, 0);

  gw.begin(incomingMessageESP, 0, true, 0);

"My" void incomingMessageESP(const MyMessage &message) is simply using the incoming values and pushing it to pimatic's REST-api.
It used to be a simple hack of the gw.begin(). I did check the examples but I'm not an experienced C-programmer. That's why I can't solve it.
I need to know where I can "hook" my function incomingMessageESP into the new 2.0 code.
I tried in the void loop() where it says // Send locally attached sensors data here as I expected that it doesn't matter whether it is local sensors or local functionality but I simply don't get it.

[Yveaux]

@Harry-van-der-Wolf Have a look at e.g. the RelayActuator.ino example.
It also waits for incoming MySensors messages on the gateway.
In 2.0.0 the gw.begin() function no longer exists, and incoming messages are automatically handled in a receive function:

void receive(const MyMessage &message) {
  ...
} 

It will replace your incomingMessageESP function.

You don't have to register it (like you did in the call to gw.begin()) , just defining it is sufficient.

[Harry van der Wolf]

@Yveaux : Thanks a lot! I have now a working version for mysensors 2.0.

It took me some time to understand the different sequence of includes, both in the top of the ino and just above the void setup(). That took almost 2 hours before I suddenly realised that I had to change the sequence of some of my definitions and statements as well.
I'm used to include "everything" in the top of my code.

[Yveaux]

@Harry-van-der-Wolf great to hear you finally nailed it!
Not sure what you mean with the include locations. It should just work fine to include everything on the top.
Might be the Arduino build system that's playing tricks..

[Harry van der Wolf]

You gave the example of the relay actuator for the function but I took the esp8266 gateway to start with.
What I mean is that you see "in the top" the spi.h and eeprom.h declarations.
Then a number of #define statements.
And just above the void setup()the MySensors.h and esp8266wifi.h are declared.
I had some definitions that required the MySensors.h and those gave errors because they were declared below the "normal" position of the includes but above the "MySensors.h". (I even considered filing a bug ticket for the missing MySensors.h )
So I declared the MySensors.h in the top of the ino below spi.h and eeprom.h (because I had not seen the MySenors.h almost at the bottom of the ino).
And then some errors were fixed and a few other arose. It took me quite some time to see that the MySensors.h was declared sooo low in the ino where I definitely had not expected it.