ad-hoc network for pimatic necessary ? - Update: Proof of Concept working

---

@koffienl said:

Yes, a pesudo-TTY from OS to the ESP. the code on the ESP is something i wrote specificly for this project.

Unfortunatly I am not an UNIX expert but highly interested in this pseudo tty for a similar use case. Can you provide some code or a short tutorial how to setup this pseudo tty?

Very simple
Install socat and after that you can create a TTY device with several options. to create a TTY that connects to a TCP port I use the command : sudo socat pty,link=/dev/ttyV0 TCP:192.168.2.118:23&

@koffienl Indeed, looks very simple. I will try it the next days. Thanks a lot!
Then I am also interested what to do on the other peer ESP-side. What is best and easiest? Is esp-link best (https://github.com/jeelabs/esp-link)?

I tried socat, but I need even parity bit, so I tried

sudo socat pty,link=/dev/ttyV0,parenb=1,parodd=0 TCP:192.168.2.118:23&

But this give an error ‘invalid argument’. With parentb=0 it works, but that is not what I need. I also found this http://carbidelabs.com/tutorials/serial-port-prototyping/ where exactly this problem is reported. But I didn’t find any solution yet.

@Icesory said:

That is interesting. Normally the library should work exact the same on the esp8266. Eventually you must change the buffer size because it isn’t declared for the esp. (in RFControl.cpp)

Anyone managed to get into this? I can’t find any strange things (also limited due to code skills from my side).
I really want to implement sending and receiving in ESPimatic, but being able to detect at least KaKu is a must for me.

I tested the code on a esp-201 and only received switch5 not kaku.
I now flashed the same sketch on to a Nodemcu v0.9 and it receives everything including kaku.

OK, time to inventory what ESP’s do work and don’t work.

I tested on this dev board : http://www.esp8266.com/wiki/doku.php?id=esp8266-dev-boards

Upgrade ESP to latest firmware, still no result:

AT version:0.60.0.0(Jan 29 2016 15:10:17)
SDK version:1.5.2(80914727)
compile time:Jan 29 2016 19:07:08 

edit : kaku-old from remote is also working (just like eurodomest).
Tommorow some more tests with @incmve

which switch protocol is it in pimatic for kaku? switch1?

@Icesory said:

which switch protocol is it in pimatic for kaku? switch1?

Yes, switch1
For me personally (and I think a lot in NL?) one of the most used protocols.

Added the command serial.swap(); to the sketch, configured the TX port as input for RF receiver.
After starting I see constant garbage on the monitor, it stops when there is a RF broadcast, after that it continues. When sending KaKu the garbage stops as well, but still nothing in Pimatic.

Assumption : Stopping the garbage is done by RFControl who is detaching the interrupt when it sees something that looks like data. Somewehre along the lines it concludes that it’s not data that looks like a protocol and attach the interrupt again ignoring the receive.

We also swapped out our RF receivers between the NodeMCU , it keeps recognizing KaKu on the NodeMCU.
Last test : power my ESP through the 3.3v OUT and GND from the NodMCU from @incmve see if that will do something positive.
^^ Powering the ESP from a NodeMCU makes no difference in results.

Got it working!!

I was sniffing around in the rfcontrol includes and saw the following in*arduino_functions.h:

#if (defined(__AVR_ATmega168__) || defined(__AVR_ATmega328P__)) && !defined(MAX_RECORDINGS)
  #define MAX_RECORDINGS 400   //In combination with Homeduino maximum 490*2Byte are possible. Higher values block the arduino
#endif
#if (defined(__AVR_ATmega32U4__) || defined(TEENSY20) || defined(__AVR_ATmega1280__) || defined(__AVR_ATmega1281__) || defined(__AVR_ATmega2560__) || defined(__AVR_ATmega2561__)) && !defined(MAX_RECORDINGS)
  #define MAX_RECORDINGS 512   //on the bigger arduino we have enough SRAM
#endif
#if !defined(MAX_RECORDINGS)
  #define MAX_RECORDINGS 255 // fallback for undefined Processor.
#endif

Since it works on a Arduino and not on ESP, I changed the MAX_RECORDINGS for undefined Processor to 400 and flashed my ESP with it.
It worked!
After yelling to @incmve this solution he then recalled he had done the same thing

lmao sorry I forgot that I changed that
I set it to 512

@Icesory said:

That is interesting. Normally the library should work exact the same on the esp8266. Eventually you must change the buffer size because it isn’t declared for the esp. (in RFControl.cpp)

That was it what I meant. The buffer size for RFControl.

We were just looking in the wrong include

Really nice. I think it is now necessary to improve pimatic-homeduino to specify sending nodes.

Yes, there are some different ways and problems to overcome.

My working proof of concept is nice, but will be a problem when the IP link times out, homeduino will see it as a disconnect and you would have to restart pimatic.

One thing to discuss is how to handle multiple nodes.
You could do a homeduino plugin that does a UDP broadcast in the network, every node cook hook up on the broadcast. Optional whitelisting could be done on the ESP side.
A other way to handle is to specify in the device the IP of the node that would handle that RF device. Homeduino plugin would the distribute the RF packets to specific destinations.

All nodes could just send their receives over the homeduino API, no need to re-invent something for that.

Allthough I’m no coder at all, is this something we can work on with multiple developpers? @mwittig has some cool ideas and working projects.

I pushed a little extension of our buffersize definition in RFControl. Can you test it on the esp?
https://github.com/pimatic/RFControl/commit/ca566d8e5f20f24403b11c2542d2b66f623c0daf

LOL wasn’t aware of using defined(ESP8266)
Can’t try now, will try this evening.

@Icesory said:

I pushed a little extension of our buffersize definition in RFControl. Can you test it on the esp?
https://github.com/pimatic/RFControl/commit/ca566d8e5f20f24403b11c2542d2b66f623c0daf

Confirmed working