ESP8266 for remote sensors and points.

Dagnall
Posts: 278
Joined: 15.05.2015, 14:41

Re: ESP8266 for remote sensors and points.

Post by Dagnall » 07.06.2016, 19:57

I shall work carefully through your comments ..
Just to let you know, I have got multi servo operation working nicely from rocrail, and plan to set the servo limits in Data1 and Data2 (user addr_user_base +1 and +2)of the SV associated with that port.
I could not see from the documentation what ucSenType a "servo" should be, but I would like to set the EEPROM reasonably close to LOCOIO SV settings.
I plan to have the other ports as either Block occupancy or digital outputs.. maybe selectable: ucSenType for these should be what?
The document you referenced has:
Input Command to send out
Currently 15 (0x0F)
47 (0x2F)
111 (0x6F) are available
Output Command to look for
Currently 192 (0xC0)
128 (0x80) are available

Which one is expected too identify "block occupany" and which "servo"??

In the code you seem to make the assumption that message will always be 16 bytes.. I agree that is what rocrail sends (so far at least), but the standard suggests that this is a variable length message.. does this need to be taken into account?

I must say I am not very impressed with the consistency of the Loconet Address/ port terminology and use. - But I can work with it...
Presumably its a legacy from small processors and expects each port to be identified with reference to a single address for that "box". And then only allows 4 ports per address?
With the code capability in the NodeMCU I could easily have each physical port addressable by any number from 1-2048, and have them all adjustable: But that would mean any attempts to make the SV's common with other devices would be impossible... On the other hand, this device is much more likely to be set via the webserver, so I am in two minds about adding the complexity to make the SV's readable (and understandable) via LocoIO.

If you still have patience.. can you confirm that to send my OPC_INPUT_REP (0xB2) command I will need to
g_udp.beginPacket(ipBroad, port);
g_udp.write(sendBLOCKMessage, 4);
g_udp.endPacket();
Where I have to build the sendBLOCKMessage, and it will start with 0xB2, with its Data is defined by
<IN1> =<0,A6,A5,A4- A3,A2,A1,A0>, 7 ls adr bits. A1,A0 select 1 of 4 inputs pairs in a DS54
<IN2> =<0,X,I,L- A10,A9,A8,A7> Report/status bits and 4 MS adr bits.
"I"=0 for DS54 "aux" inputs and 1 for "switch" inputs mapped to 4K SENSOR space.
(This is effectively a least significant adr bit when using DS54 input configuration)
"L"=0 for input SENSOR now 0V (LO) , 1 for Input sensor >=+6V (HI)
"X"=1, control bit , 0 is RESERVED for future!
and A0-A10 are the "address" that Rocrail will be looking for in its "BUS" and "Address" Interface settings.

Many thanks again.. I will upload a sketch when its working a bit better...
Dagnall

Liviu M
Posts: 942
Joined: 03.12.2011, 20:44

Re: ESP8266 for remote sensors and points.

Post by Liviu M » 07.06.2016, 20:29

Hi,
yes, ucSenType (should be better named ucPortType) keeps the type of each port. The type is received from Rocrail as the first byte of the three describing a port in the LocoIO.
I think the original outputs were not supposed to work with servos. Later, an "extension" seems to be added. In the LocoIO menu in the Rocrail, the last tab is dedicated to servos. The information in this area occupy some higher addresses (over 100?), code for left position and code for right position. I haven't done any research in this direction, no idea how it exactly works, you should "sniff" the packages the Rocrail sends.
Ans yes, for me your messages seems correctly build.

Regards,
Liviu

PS If you fill you are "constraint" by Loconet protocol, you can try one from the others Rocrais supports. Between them there are some more open protocols. I suppose Rob can give you a better advice about them.

Dagnall
Posts: 278
Joined: 15.05.2015, 14:41

Re: ESP8266 for remote sensors and points.

Post by Dagnall » 09.06.2016, 11:09

HI, A quick update:
My hacked code now has four servos working on command, on ports D1- D4. I did have port DO working, but it seemed to give up after I changed to multiple servos. Not sure if this is my hardware or software... I only have one ESP12E for the time being.

I have had some horrendous crashes whilst modifying the code, all caused by silly typos or missed "(" or ")".. Some have taken hours to find...

I have been "sniffing" the BO message from rocrail and note that the message actually has a payload of two bits.. "thrown" and "ON".. I therefore check for these at the beginning of my OPC_SW_REQ code..
if(recMessage[0]==OPC_SW_REQ) { // this is a switch command
b0mesagethrown=bitRead(recMessage[2],5);
b0messageon =bitRead(recMessage[2],4);
I then set the servo depending on the "thrown" bit.
"Sniffing" more deeply I managed to get the three way points_switch to send both bits, giving me three positions, so I have interpreted the middle position as "average of the two extreme settings", to keep the settings for each port at two bytes..
I have been looking at the lights, and possibly there are some that can send all four options, but I have not found them yet.

Given this, I propose that my version of ucSenType (as you say, ..should be better named ucPortType), will have to have a number of "input" options, to cover how to respond to "thrown" and "ON". -
Equally, when I send using the B2 Message, I will have
<IN2> =<0,X,I,L- A10,A9,A8,A7>
where "X,I,L" are described as ...
"I"=0 for DS54 "aux" inputs and 1 for "switch" inputs mapped to 4K SENSOR space.
(This is effectively a least significant adr bit when using DS54 input configuration)
"L"=0 for input SENSOR now 0V (LO) , 1 for Input sensor >=+6V (HI)
"X"=1, control bit , 0 is RESERVED for future!
NOT very helpful...! I will have to do some sniffing to see how that relates to Rocrail..

I am also a little confused why you set
uiAddrSenFull = 256 * (EEPROM.read(ADDR_USER_BASE+2) & 0x0F) + 2 * EEPROM.read(ADDR_USER_BASE + 1) +
((EEPROM.read(ADDR_USER_BASE+2) & 0x20) >> 5) + 1;
I am not sure why the code needs to be that complex? ..I must admit that I have not explored this function in full, but it looked quite "obscure" to me..
The address code in all cases I have found so far is organised:
EXAMPLE: <0xB2>, <IN1>, <IN2>, <CHK>
<IN1> =<0,A6,A5,A4- A3,A2,A1,A0>, 7 ls adr bits. A1,A0
<IN2> =<0,X,I,L- A10,A9,A8,A7> Report/status bits and 4 MS adr bits.
So my sensor address code (one per servo port, indexed i at the moment) is therefore:
{ uiBoardAddrFull = (128*(ucBoardAddrHi&0x0F))+(ucBoardAddrLo&0x7F);]
Give or take a "+1" to make it fit with what Rocrail sends.... ,
calcAddressByte is then modified to reflect this :
void calcAddrBytes(uint16_t uiFull, uint8_t *uiLo, uint8_t *uiHi){ // modified by Dagnall.
*uiLo = ((uiFull ) & 0x7F);
*uiHi = ((uiFull - *uiLo)/128);
}
My code skills are very rusty, and I liked PASCAL, had headaches with "B" and never really used C or C++ except as for very simple playing with Arduino, so I may have missed some subtle details?

Liviu M
Posts: 942
Joined: 03.12.2011, 20:44

Re: ESP8266 for remote sensors and points.

Post by Liviu M » 09.06.2016, 11:52

Hi,

not much time now, just some point about addresses conversions.
Dagnall wrote: I am also a little confused why you set
uiAddrSenFull = 256 * (EEPROM.read(ADDR_USER_BASE+2) & 0x0F) + 2 * EEPROM.read(ADDR_USER_BASE + 1) +
((EEPROM.read(ADDR_USER_BASE+2) & 0x20) >> 5) + 1;
I am not sure why the code needs to be that complex? ..
It is the conversion in the full sensor address of the address bytes sent by Rocrail in the E5 messages. To understand why it is so complicated (and maybe make it better), you should play with some "special" values 1, 2, 127, 128, 1023, 1024, 2047, 2048. Ive arrived to this formula through trial and error method (maybe it can be derived from the LocoIO documentation), so maybe an "objective" eye can improve it.
Dagnall wrote: The address code in all cases I have found so far is organised:
EXAMPLE: <0xB2>, <IN1>, <IN2>, <CHK>
<IN1> =<0,A6,A5,A4- A3,A2,A1,A0>, 7 ls adr bits. A1,A0
<IN2> =<0,X,I,L- A10,A9,A8,A7> Report/status bits and 4 MS adr bits.
So my sensor address code (one per servo port, indexed i at the moment) is therefore:
{ uiBoardAddrFull = (128*(ucBoardAddrHi&0x0F))+(ucBoardAddrLo&0x7F);]
As said, we are putting different things in the same variable. I'm combining the the address bytes from the programming messages, you are combining the bytes from the reporting messages. But (in my approach) calculating the full address with the "reporting bytes" is unnecessary. I'm calculating the "reporting bytes" (with my strange function) once after a programming session and afterwards I'm using them directly.
Dagnall wrote: Give or take a "+1" to make it fit with what Rocrail sends.... ,
calcAddressByte is then modified to reflect this :
void calcAddrBytes(uint16_t uiFull, uint8_t *uiLo, uint8_t *uiHi){ // modified by Dagnall.
*uiLo = ((uiFull ) & 0x7F);
*uiHi = ((uiFull - *uiLo)/128);
}
I must check it, but I think I was splitting the full address (calculated from the "programming bytes") in the hi/low reporting address bytes as in the documentation.
"I"=0 for DS54 "aux" inputs and 1 for "switch" inputs mapped to 4K SENSOR space.
(This is effectively a least significant adr bit when using DS54 input configuration)
With other words, I'm taking the full address' lsb and put it as the 5th bit in the hi address byte. I'm "filling" the place freed in the low byte by shifting it to the right.

I think the different results are coming from different approaches. As long as they are working, I suppose any of them can be used. I'm used with mine, so I suppose I'll stick with it. Feel free to use your approach if it is better suited for you.

Regards,
Liviu

Dagnall
Posts: 278
Joined: 15.05.2015, 14:41

Re: ESP8266 for remote sensors and points.

Post by Dagnall » 10.06.2016, 17:28

Hi again, !
I decided to get ESP8266 sending message back to Rocrail as my next priority, before I try to make the SV's look like existing hardware examples...

With this in mind, I have implemented a single input port switch function with software debounce that seems to work ok. (and which I can easily "index" later).
It reliably sends a serial message when the state is changed.... (HINT... make the switch/resistor combination pull down the input to 0V, and not UP to 5V... At my age I should have known better and now I think I now have one destroyed input pin... grrrr).

I then built my own version of the code for the "Build a sendmessage", based heavily on yours...
void setResponseMessage(uint8_t *SendPacketSensor, int i){ //response message using OPC_INPUT_REP (0xB2) for which input set by i
unsigned char k = 0;
SendPacketSensor[0] = OPC_INPUT_REP;// //OPC_INPUT_REP
calcAddrBytes(uiAddrSenFull, &SendPacketSensor[1], &SendPacketSensor[2]);// setting address bits..<IN1> =<0,A6,A5,A4- A3,A2,A1,A0>,
// and address HI of <IN2> =<0,X,I,L- A10,A9,A8,A7> Report/status bits (yet to be set..)and 4 MS adr bits.
bitSet(SendPacketSensor[2],6); // set bit X "control bit"
if (BoardInput){ // NOW set "L-" of <IN2> =<0,X,I,L- A10,A9,A8,A7>
bitClear(SendPacketSensor[2],4); } // crude code, but easy to follow and modify....
else {bitSet(SendPacketSensor[2],4); }
bitSet(SendPacketSensor[2],5); // set the DS54 bit for switch" inputs mapped to 4K sensor space.."
SendPacketSensor[3]=0xFF;
for(k=0; k<3;k++){ // Make checksum for this three byte message
SendPacketSensor[3] ^= SendPacketSensor[k];
}
}


This is called when I sense a switch change (currently only on index "7") and need to send the message to ROCRAIL..
Eventually the sensor address will also be indexed by the index ( "7" in this test code)

// try sending
if(BoardInput[7]!=LastInput[7]) {
LastDebounceTime= LastDebounceTime+1;
if (LastDebounceTime>DebounceDelay){
Serial.print("Switch status send: ");
Serial.println(BoardInput[7]);
LastInput[7]=BoardInput[7];
LastDebounceTime=0;
setResponseMessage(SendPacketSensor,7);

#if _SERIAL_DEBUG
// Show some details of the message
Serial.print(F("BLOCK send mess:"));
dump_byte_array(SendPacketSensor, 4); //set to 4 bytes..
Serial.println();
#endif
g_udp.beginPacket(ipBroad, port);
g_udp.write(SendPacketSensor, 4); // set to 4 bytes length
g_udp.endPacket();
}
}



With my sensor address set to 04
this sends to the serial... :

Switch status send: 0
BLOCK send mess: B2 04 70 39
Switch status send: 1
BLOCK send mess: B2 04 60 29

This looks like the code examples in http://www.locobuffer.com/LocoIO/LocoIO.pdf
I think the checksum is correct, I tested the code with a B0 example and it looked the same as Rocrail sent..
I have tested the sensor code both with and without the DS54 bit set...with identical results..

To help test, I set up a series of 8 sensors in Rocrail with interface properties set to: Bus 0 Address 1 - 4, and also Bus 1 Address 1 -4, expecting one at least to change state All were set as "Sensor".. with the reset box ticked

But when I pressed my button..... no results, no changes......

I'm assuming that I have either missed something about how to send the response back to Rocrail, or the addressing..

Is the following g_udp code going to send the message I expect it to? or is there anything missing (setups perhaps?).

g_udp.beginPacket(ipBroad, port);
g_udp.write(SendPacketSensor, 4); // set to 4 bytes length
g_udp.endPacket();


Or is it my setting of the Rocrail Block sensors??? I fully appreciate that I may have completely misunderstood the ROCRAIL sensor addressing structure...But My CanBUS stuff works fine, and I was assuming the LocoIO would be very similar...
I do not have any "real" LocoIO stuff to "sniff".....And I have not found any "sniffer" in rocrail that could confirm I was actually sending it any data..

Or does Rocrail look for a different message from LocoIO to set/change the sensor states?

Many thanks again...
Dagnall

Liviu M
Posts: 942
Joined: 03.12.2011, 20:44

Re: ESP8266 for remote sensors and points.

Post by Liviu M » 10.06.2016, 20:25

Hi Dagnall,
sorry, I don't have much time now neither, but I have few observation.
In my approach, I already have the sensor (reporting) addresses - A10..A0, I - calculated, I put the X=1 also and I just make the L = 0 for sensor low and L = 1 for sensor High.
So, my reporting messages are looking like (shifting the real address and naming the I as A0):
<OPC_INPUT_REP><0,A7,A6,A5- A4,A3,A2,A1><0,1,A0, 0, A11,A10,A9,A8><CRC> for sensor low and
<OPC_INPUT_REP><0,A7,A6,A5- A4,A3,A2,A1><0,1,A0, 1, A11,A10,A9,A8><CRC> for sensor high.

So, if the sensor address is 5 (101), I'll send:
0xB2 0x02 0x40 0x0F for sensor low and
0xB2 0x02 0x60 0x2F for sensor high.
These messages are for sure correctly decoded by Rocrail (I have some PIC boards working with messages codded in this way).

Regards,
Liviu

PS CRC is correct if XOR-ing all bytes (CRC inclusive) is FF.

Later edit: sorry, second and third bytes were interchanged. Corrected.
Last edited by Liviu M on 10.06.2016, 21:00, edited 1 time in total.

Liviu M
Posts: 942
Joined: 03.12.2011, 20:44

Re: ESP8266 for remote sensors and points.

Post by Liviu M » 10.06.2016, 20:49

If I'm not interpreting anything wrong, your message B2 04 70 39 will be decoded by Rocrail as:
04 => Addr2 = 1.

Code: Select all

0 A6 A5 A4 A3 A2 A1 A0
0 0  0  0  0  1  0  0
70 => I = 1.

Code: Select all

0 X I  L- A10 A9 A8 A7
0 1 1  1  0   0  0  0
Total address as decoded by Rocrail will be 0x009.

Code: Select all

A10 A9 A8 A7 A6 A5 A4 A3 A2 A1 A0 I
0   0  0  0  0  0  0  0  1  0  0  1
Anyway, if you activate the byte traces in Rocrail and the messages are right formatted, you should see all you send in the server's terminal.

Regards,
Liviu

Dagnall
Posts: 278
Joined: 15.05.2015, 14:41

Re: ESP8266 for remote sensors and points.

Post by Dagnall » 10.06.2016, 22:30

Yes, I think your interpretation makes sense: I found some Italian code http://www.rmweb.co.uk/community/index. ... -detector/
{
That built the B2 Message like this:
SendPacketSensor[0] = OPC_INPUT_REP; //OPC_INPUT_REP
tempaddr = uiAddrSenFull + i;
SendPacketSensor[1] = tempaddr;
SendPacketSensor[1] = SendPacketSensor[1] >> 1;
bitClear (SendPacketSensor[1],7);
bitSet (SendPacketSensor[2],6);
bitWrite (SendPacketSensor[2],5, bitRead(tempaddr,0));
bitWrite (SendPacketSensor[2],4, !BoardInput);

SendPacketSensor[3]=0xFF;
for(k=0; k<3;k++){ //Make checksum for this three byte message
SendPacketSensor[3] ^= SendPacketSensor[k];

This clarifies that the I Bit is set to sensorAddr,0, and that the rest of the address is effectively multiplied by two...

With a base SA of "1", my version of this code sends the following with the base address at 1 for i=7:
Switch status send: 0
BLOCK send mess I version: B2 04 51 18
Switch status send: 1
BLOCK send mess I version: B2 04 41 08

If I have this right, (done manually....)
The codes that this is sending are:
04 41 and 04 51 and these give
<IN1> =<0,A6,A5,A4- A3,A2,A1,A0>, set at 04
<IN2> =<0,X,I,L- A10,A9,A8,A7> set at 41 or 51
Gives
A10 A9 A8 A7 A6 A5 A4 A3 A2 A1 A0 I
0 0 0 1 0 0 0 0 1 0 0 0
I make this address 256(A7)+(A2)8 = 264 and it shows switching of the "L-" state.
Sadly setting 264, 265 or 263 in the rocrail interface does not produce any response..

Rocrail can send my "switch commands", to the ESP but the multiple presses of my "Route button" in between do not seem to be noticed or recorded by Rocrail...
Even looking at the trace files shows no messages from the ESP... and makes me suspicious I have missed something in the "send" coding...
g_udp.beginPacket(ipBroad, port);
g_udp.write(SendPacketSensor, 4); // set to 4 bytes length
g_udp.endPacket();

I presume that ipBroad and Port are the same as for the read messages ?
set by..
[quoteIPAddress ipBroad(224,0,0,1);
const int port = 1235;
][/quote]
Is it necessary to flush the g-udp or check its connected just before this code?
do we need any delays before we do this?
also, Is the ipServer commented out code needed??

g_udp.beginPacket(ipBroad, port);
// g_udp.beginPacket(ipServer, port);
g_udp.write(sendMessage, 16);
g_udp.endPacket();


I am beginning to think that this is rather more complex than when I started!!.
Just to check, when I set up a sensor, I set Bus 0 Address = the address I'm looking for (example address 265 attached) ( set a few up so I can check for address + and - 1)

not really sure what else to try!
Thanks again for your help!


Dagnall
You do not have the required permissions to view the files attached to this post.

Dagnall
Posts: 278
Joined: 15.05.2015, 14:41

Re: ESP8266 for remote sensors and points.

Post by Dagnall » 11.06.2016, 20:35

Liviu,
With my new ESP12 board working I have simply coded in your RFID2Wifi stuff, cleared the eprom, and am looking at the Roocrail trace compared to the Serial comms trace.
I have attached a picture of what I see.
Unless I am completely misunderstanding the traces, the Rocrail trace shows it sending

Code: Select all

20160611.201848.880 r9999B lnwriter OLocoNet 0286 *** transact dump:
    00000000: E5 10 50 00 01 00 02 00 00 00 00 00 00 00 00 59 |..P............Y|
20160611.201848.880 r0000B lnwriter OLocoNet *trace dump( 0x03BDFE8D: length=16 )
    offset:   00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F |ASCII...........|
    --------------------------------------------------------- |----------------|
    00000000: E5 10 50 00 01 00 02 00 00 00 00 00 00 00 00 59 |..P............Y|
Same as the serial monitor shows the ESP Receiving..(LNxfer rec mess...)
But then the ESP serial monitor says it is sending "LN xfer send mess: E5 10 59 50 01 00 02 00 01 7B 00 01 36 01 59 15"
But the Rocrail trace says it actually receives

Code: Select all

20160611.201848.896 r0000B lnreader OLocoNet *trace dump( 0x0399FE68: length=16 )
    offset:   00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F |ASCII...........|
    --------------------------------------------------------- |----------------|
    00000000: E5 10 50 00 01 00 02 00 00 00 00 00 00 00 00 59 |..P............Y|
20160611.201848.896 r9999c lnreader OLocoNet 1275 LocoIO SV response
I.E, the same that it sent.....
( pressed the "power button " before and after this message test, and can see the command 52 7D clearly after the ESP send message...)

I will keep hacking, but have I understood the Rocrail trace and the ESP serial debug monitor correctly....
Is there a sensible reason why the esp code is not being sent as reported in the serial debug monitor?

Looking forward to your next note!

Dagnall
response_not_Equal_comms_debug.jpg
You do not have the required permissions to view the files attached to this post.

Liviu M
Posts: 942
Joined: 03.12.2011, 20:44

Re: ESP8266 for remote sensors and points.

Post by Liviu M » 12.06.2016, 09:34

Hi Dagnall,

you should first fix your wifi communication. You should be able to receive some messages on PC, during programming and sensors activity.
I'm attaching a sketch in which I've removed any RFID code and which emulate a sensor at the address 5. It sends every second a message from this sensor, once 1, once 0. You don't need any extra hardware to test it. I've discovered an error in the messages from my previous post, they were sensor 5 & 6 low. In the sketch are the right ones (sensor hi, sensor low) for sensor 5.
I'm attaching also a screen shot with the server's terminal during a programming session (E5 messages). Because the sensor is "working" in this time, you can see the both message types (E5 & B2) mixed.
You should reach this state; further steps are useless before.
Because with the firewall wrong configured I had the same problems as you (could receive messages on ESP but not on PC), I'll repeat the Rob's advice - remove your connection to Internet, stop your firewall and try again.
Now I'll try to answer some of your questions from previous messages:
- ipServer is not used
- for RFID messages we are using the E4 messages with 7 bytes for the RFID ID. The message is "invented" by Rob and I as extension to some Uhlenbrock messages. Info - in the wiki.
- I can't help much with hardware problems.
- to test the communication,you don't need any hardware. In the attached sketch I'm sending messages without having any sensor defined.

Regards,
Liviu

LE Uploaded the correct files.
You do not have the required permissions to view the files attached to this post.

Liviu M
Posts: 942
Joined: 03.12.2011, 20:44

Re: ESP8266 for remote sensors and points.

Post by Liviu M » 12.06.2016, 12:44

Ah, another hint. Because I suppose you have more than one network adapter in your server PC, don't forget the Rob's advice to put the IP of the server's wlan adapter in the Local IP field when you configure the Loconet LNUDP CS.
I, for example, I've put jn this field 192.168.1.23, because this is my laptop's wlan IP; the ESP has 192.168.1.12.
Regards,
Liviu

Dagnall
Posts: 278
Joined: 15.05.2015, 14:41

Re: ESP8266 for remote sensors and points.

Post by Dagnall » 14.06.2016, 17:59

Hi all, I have some code now working well, but it also introduces some questions about the 224.0.0.1..

On advice from my "systems and networking specialist", I have used the code below as a test, an it worked to send to Rocrail, first time.

It sends to both my rocrail setups that I have here for test.
Both have Loconet controller, one set to Hostname 224.0.0.1 with local Ip also filled in.
The other is set to Hostname 192.168.0.255 which I understand is the Broadcast address in my domain range. This setup does not have the local IP set.

With my latest code, both can set a servo on my ESP, and both receive commands from the ESP to set blocks.

Given I have everything now working, I am not that concerned about the 224.0.0.1 address, but I do wonder why it was suggested that this MUST be used?

I am rebuilding my Servo/Sensor code slowly, and currently have the servos working (and the sensor packet automatically sending every few seconds), I did find that uploading the sketch to the ESP can be unreliable, but pressing "upload" again on the Arduino interface usually solves the problem....

Next I plan to add a proper debounced interface for the switches and then I will upload it here for anyone else to develop if they wish..

After that I will add in the EEPROM stuff and HTML interface slowly, but It is at least now working ok.
Perhaps when I get the EEPROM stuff in, we can talk about how to organise the EEPROM so that Rocrail's existing Loconet interface stuff can be used to set and read settings such as the board address, sensor address and servo positions ?

All the Best
Dagnall


This is the very simple raw code that got me working in the end....

Code: Select all

#include <ESP8266WiFi.h>
#include <WiFiClient.h>
#include <WiFiUDP.h>

String wifiSSID = "ssid";
String wifiPassword = "pass";

WiFiUDP UDP;
IPAddress ipBroad;
const int port = 1235;
byte udpTestPacket0[] = {0xB2, 0x02, 0x50, 0x1F};
byte udpTestPacket1[] = {0xB2, 0x02, 0x40, 0x0F};
bool p=0;

void setup() {
  Serial.begin(115200);
  WiFi.mode(WIFI_STA);
  WiFi.begin(wifiSSID.c_str(), wifiPassword.c_str());
  while (WiFi.status() != WL_CONNECTED) {delay(500);Serial.print(".");}
  Serial.println();
  Serial.println(WiFi.localIP());
  ipBroad=WiFi.localIP();
  ipBroad[3]=255; //Set broadcast to local broadcast ip e.g. 192.168.0.255
}

void loop() {
  UDP.beginPacket(ipBroad, port);
  if(p){
    UDP.write(udpTestPacket0,sizeof(udpTestPacket0));
  } else {
    UDP.write(udpTestPacket1,sizeof(udpTestPacket1));
  }
  UDP.endPacket();
  p=!p;
  Serial.println(F("UDP Packet sent"));
  delay(1000);
}

Liviu M
Posts: 942
Joined: 03.12.2011, 20:44

Re: ESP8266 for remote sensors and points.

Post by Liviu M » 14.06.2016, 18:10

Hi Dagnall,

nice to hear it is finally working.
I don't know why 224.0.0.1 was choose, maybe Rob will clear us.
The only reason I can think about, is that you do not need to care about the network settings - you put 224.0.0.1 and it normally works.
But I suppose, as long you are consistent, you can put other (broadcast) IP in the ESP and Rocrail.

Cheers,
Liviu

Dagnall
Posts: 278
Joined: 15.05.2015, 14:41

Re: ESP8266 for remote sensors and points.

Post by Dagnall » 15.06.2016, 18:41

At last I have some code that is working enough to be useful ..
four inputs and four servos.
The inputs (D5,D6,D7,D9) all send "B2" messages from "SensorAddress" as defined in the Defaults.h, (D6= SensorAddress +1 etc).
When I tried to use "input" on D8, it would not work.. This may be my board, I simply avoided it and have set the fourth input on D9.
(PS USE A PULL DOWN switch.. to avoid connecting the ESP pins to 5V... :oops: )
There is some de bounce included, and a Loop delay of 50ms in line 111.

The Servos are all connected to D1,D2,D3,D4 and have individual throws for Straight and Thrown, plus a "Mid" position that can be called from a three way button or track switch. D1 is controlled by the "Board Address", as defined in Defaults.h.; D2 by Address+1 etc.

Output D0 on my board has a LED, which I use for debug testing etc, so I may use it later for a relay..

I have not yet set the EEPROM system or HTML interface, as it is working "enough" for me for now...

I need to stop playing with this for a while now and concentrate on other things, but if you have any recommendations for how I should organise the EEPROM data so that Rocrail can program it, let me know.

Thanks again all.
:beer:
Dagnall
You do not have the required permissions to view the files attached to this post.

Liviu M
Posts: 942
Joined: 03.12.2011, 20:44

Re: ESP8266 for remote sensors and points.

Post by Liviu M » 15.06.2016, 18:54

Hi Dagnall,
Dagnall wrote:but if you have any recommendations for how I should organise the EEPROM data so that Rocrail can program it, let me know.
It is already implemented in my sketch. :wink:

Cheers,
Liviu

Post Reply

Return to “DIY Hardware”