uMQTT 192.168.4.1 about esp_wifi_repeater HOT 73 CLOSED

Tried to connect from both sides simultaneously - from AP and STA with the IP of either side (). Works just fine. Maybe you experience problems with MQTT version?

from esp_wifi_repeater.

Hi Martin
I'm using your last version of the firmware (MQTT 3.1.1 compliant) with the below ESP8266 Mqtt libraries:
https://github.com/256dpi/arduino-mqtt
https://github.com/knolleary/pubsubclient

When I connect using the STA IP all works fine, while when I use the AP IP the 2 libraries return that the MQTT connection has not established.
My concerns are:

• using STA IP all works, so there isn't any problem with my ino code
• also It's strange that the problem exist with 2 different libraries (one is not derived from the other one)

How you have made your test? I could tray to replicate it.

How can I download the previous version of your firmware compliant only with MQTT 3.1?

Thank You

from esp_wifi_repeater.

I have done a further test with python using my linux PC: MQTT_Publish_Test_00.py
The script works with AP and STA using "paho.mqtt.client" python library

I think that the issue is something related to the ESP8266 implementation of the MQTT libraries or how the TCP client is managed.
Do you have experience with the MQTT libraries for ESP8266 using Arduino IDE?

from esp_wifi_repeater.

I have simplified the test ino file
If ESP8266 connects the STA IP there is the MQTT connection.
If ESP8266 connect the AP IP(192.168.4.1) now there is the MQTT connection

I have added the row
WiFi.mode(WIFI_STA);

This is quite strange but works!

from esp_wifi_repeater.

As the WiFi mode seems to be the crucial point, I would guess that it is really a lower level problem, not one of the MQTT protocol.

Just checked in a version that accepts MQTT v3.1 and v3.1.1 clients at the same time.

from esp_wifi_repeater.

Migrated the uMQTT broker into a new project without the NAT feature: https://github.com/martin-ger/esp_mqtt
This saves RAM and allows for more TCP connections. I tested with 8 yesterday. Also it simplifies the compile process as it doesn't require the modified lwip library any more, the standard SDK should be sufficient

from esp_wifi_repeater.

I have updated my blog with your new Git version

from esp_wifi_repeater.

from esp_wifi_repeater.

Hi Martin
Good Job! The MQTT-bridge it's a good idea!
Another application is the 1st uMQTT broker sends the messages to another uMQTT broker to extend the ESPs network

from esp_wifi_repeater.

Hello Martin,
I am very interested in your MQTT Broker/Bridge on the ESP8266 ); https://github.com/martin-ger/esp_mqtt

For about 15 years I am using Homevision (http://www.csi3.com/homevis2.htm ) to control my home lighting via X10 transmission and several other tasks. Now I am transferring my hallogene lights to LED (they consume less power), also using Sonoff Wifi units and Tasmota software (see github) for Wifi control. That works already quite well, but it also needs a PC, via RS232 attached to the Homevision unit 24/7, in order to transmit the Homevision commands via HTTP and/or MQTT to Sonof Wifi units.
I have several Sonoff units working and they all need to be controlled via Wifi reliable, simple and if possible: no PC 24/7. I use a local mqtt broker on a PC now.

Separate is the e-mail correspondence with HomevisionXL expert Ron Boston (USA), who made an MQTT plugin between Homevision and a permanently attached PC (see: attached file and (http): https://github.com/rebel7580/ESP8266-Wemo-and-HomeVisionXL-Plug-in and (tcp): https://github.com/rebel7580/ESP8266-Alexa_Skills_Thermostat ).
Ron thinks that your solution could be implemented, so eliminating an attached PC with mqtt on it.
But I am not a coding guy and do need assistance/guidance from an expert like you.
Can you help me out in this matter?
If it all works well and is simple to implement a lot of other Homevison users may also be interested.
The main execution service that I need from the ESP 8266 mqtt broker is ‘the Power On and Off’ instructions for the Sonoff units and possibly: its status feedback (is a Homevision flag set/clear).
Extra features (like temperature values transfer, etc) are not needed via wifi in my situation.
Waiting for your reply and kind regards,
Harry Hendriks
The Netherlands
2017 HomevisonXLplusMQTT.docx

from esp_wifi_repeater.

Hello Harry,
I would love to see the esp_uMQTT_broker working in your environment and if can, I would like to support this.

What I don't understand so far is the exact setup of your system: The Homevision box has a serial interface and talks to a PC? Who issues the MQTT requests? The PC as result of the serial input? The Homevision itself? Who runs the plugin?

The esp_uMQTT_broker as is can send text to the serial output (but it will probably send some other output as well) but it currently cannot read input from there (other than CLI commands). Probably we'll need a special program that can do the job...

from esp_wifi_repeater.

from esp_wifi_repeater.

from esp_wifi_repeater.

Actually, there is already a command on the CLI. If you send:
publish local [topic] [data]
this will be published to the broker and any subscribed client will revceive this topic.

Caveats are: currently the serial interface is always configured for 115200 bps and it will print some infos (warnings, errors) during operation (not relevant as long as you only need this direction).

from esp_wifi_repeater.

We'd need to drop the speed down to 19200. Possible?

from esp_wifi_repeater.

No problem, will make that a config parameter.

from esp_wifi_repeater.

Done - on the CLI use:
set bitrate [bps]
to change the serial bitrate (default is still 115200) and
set system_output 0
to stop any info/warning output from the system. CLI input and acks are still printed as well as script "print"s.

In a script you can enforce these settings e.g. with

% Config params, overwrite any previous settings from the commandline
config bitrate	19200
config system_output	0

from esp_wifi_repeater.

Please note that this refers to the new project at: https://github.com/martin-ger/esp_mqtt

from esp_wifi_repeater.

Great! Thanks for the quick response!!

from esp_wifi_repeater.

Added some more features to allow for full handling of the serial interface in a script. If you can define for both directions:

• HV--> ESP: which serial output should result in which MQTT message pub and
• HV<--ESP: which received MQTT message should lead to which serial input

it should be reasonable easy to write this script.

from esp_wifi_repeater.

We may need to be able to turn off the command prompt. Not sure if your new system_output would do that. HV collects incoming chars until it sees a carriage return

HV to ESP:
For this direction, I think we can use the existing publish command. The HV sw would issue a publish command when it wants to turn on/off a device. Ex.:

To do this: publish local cmnd/livingroom/POWER on

HV would execute this code:

 Serial port 3 : Transmit string "publish local cmnd/livingroom/POWER on"
 Serial port 3 : Transmit Carriage return and Line feed

The ESP should see publish local cmnd/livingroom/POWER on\r\n where \r\n -> 0x0d 0x0a
The HV expects no response.

ESP to HV:
For this direction, it looks like a simple script can do what we need.
A script receives on or off command msg and sets the appropriate flag. I think it should look something like this:

on init
do
    subscribe local stat/livingroom/POWER
    subscribe local stat/bedroom/POWER
    ... (additional subscribes, one for each of the remaining devices)

% livingroom -> flag 10
on topic local stat/livingroom/POWER
do
    if $this_data = "on" then
        println ",>0A01"
    else
        if $this_data = "off" then
            println ",>0A00"
        endif
    endif
   
% bedroom -> flag 11
on topic local stat/bedroom/POWER
do
    if $this_data = "on" then
        println ",>0B01"
    else
        if $this_data = "off" then
            println ",>0B00"
        endif
    endif

... (additional similar "on topic"s for each remaining device)

The ",>XXYY" command sets/clears HV's Flag XX according to value of YY. This format mimics the standard commands HV can receive from a PC connected to the main serial port. However, since we are actually connecting to a second serial port, which doesn't automatically respond to standard commands, we will write our own (simple) command handling event code in HV to process them. It is just convenient to use the same format, since it is concise. But we could use any unique strings here.

The HV is expecting the string to be terminated by a carriage return (0x0d). I'm assuming that println will do that.
The HV will not generate any response to these messages

There's more that should be included in a real script, esp. in init, like using your new set baud rate, stop output, etc. , but this should show what we are trying to do.

I have some minor concern about flow control (since there isn't any in this proposal), but I think we should only worry about that if it becomes a problem. For example, once a message is received and terminated, the HV will run its event to process the message. Until that processing is complete, any additional incoming characters (e.g., a new message coming immediately thereafter) will be ignored.

from esp_wifi_repeater.

Just re-reading the scripting readme, I noticed that the "serial" event seems to capture any incoming command, instead of the command going to the CLI processor, if "system_output" is set to 0, as you recommended above. So that means we would have to add in a "on serial" command and then parse the string to create the publish command we'd need? If so, that means we could shorten the command we send a little, maybe remove "local", shorten "publish" to "pub".

from esp_wifi_repeater.

from esp_wifi_repeater.

I want to make sure I'm clear on this:

If we have system_output = 0, then NO CLI commands are valid via the serial port, and we MUST write an "on serial" event to capture our incoming (from HV) "publish" command.

Will the web console at port 7777 of the AP still work if we need to access the Console?

Also, the incoming char string will terminate in CR/LF (0d 0a). The serial event description in the scripting ReadMe say the incoming strings need to be terminated with a CR. What char(s) do you actually mean here? I think we can send whatever is needed, but the CR/LF is easiest.
Thanks!

from esp_wifi_repeater.

from esp_wifi_repeater.

OK, Thanks1 We'll terminate our incoming strings with just a 0x0D.

from esp_wifi_repeater.

from esp_wifi_repeater.

Sorry, don't see any attachment, but maybe this helps:

Sometimes, especially on old ESP-01s, there is a wrong or non-matching version of "esp_init_data_default.bin" in the flash. If the firmware files from above flash correctly but after reboot you see only garbage on the serial and/or the LED on GPIO2 is flashing rapidly, try to re-initialize this sector: download https://github.com/espressif/ESP8266_NONOS_SDK/blob/master/bin/esp_init_data_default.bin?raw=true and flash it to 0x7c000 for 512 kB modules (some ESP-01, Sonoff Switch), 0xfc000 for 1 MB modules (most ESP-01), or 0x3fc000 for 4 MB modules (most ESP-12, Wemos D1).

from esp_wifi_repeater.

from esp_wifi_repeater.

Sorry, still don't see the attachment. Could you post it Here as inline text?

from esp_wifi_repeater.

from esp_wifi_repeater.

Hello Martin,
I tried tot flash an esp12e via my Win10 PC via an USB link (on both sides).
Used download tool : https://espressif.com/en/support/download/other-tools
Binaries: https://github.com/martin-ger/esp_mqtt/tree/master/firmware
Flashing seems to complete OK (led on esp blinks during the process).
But after the subsequent ‘power off/on of the esp’ no luck with the terminal link (used atom, Arduino ide and putty in vain). See the attachments for example output.

What is your advise to proceed?

Kind regards

Harry

from esp_wifi_repeater.

Flash params look fine. Please try to verify the SHA1 checksums of the firmware files. Especially on Windows you might have corruption of binary files caused by the CR/LF problem when downloading. Did you download the firmware files separately? If so. try to download the complete zip-file and extract them. Any difference?

from esp_wifi_repeater.

Martin,
Dowloaded as zip, SHA1 checked + tried several times to flash the bin files, but still no luck.
Non performance exactly as before.
So I checked (again) the correct functioning of the ESP 12E 8266 module with other scetches.
With Arduino-IDE I compiled and downloaded to the esp :

• a blink scetch

• Wifi ScanNetworks scetch.
  No problems at all with this action and both worked OK.

After these successful tests my perception is also that the download to the esp module of the two esp-mqtt bin files via the downloadtool : https://espressif.com/en/support/download/other-tools esp takes far less time to complete than the two above mentioned scetches. Could that indicate that the code is not completely downloaded to the Esp and if so what next?

Since compiling and downloading via Arduino IDE is already working fine (see above) my question to you: is it possible to have:
a) a complete scetch that I can compile and download with Arduino IDE, or
b) a bin file compatible with Arduino IDE (import it) and download that to the esp?
c) or use Atom to do the job via importing a complete scetch + compiling + downloading to esp
If that works well the cause of the previous problems is related to the download tool usage/performance and we do have a successful alternative.

Help is very much appreciated,
thx Harry

from esp_wifi_repeater.

Harry -
Did you try DIO instead of QIO mode to flash? (I don't know what the difference is, but Martin suggested this in his ReadMe, so I thought I'd mention that.)
Ron

from esp_wifi_repeater.

from esp_wifi_repeater.

Martin, Ron,
Also tried DIO. After downloading the bin files as usual, disconnecting and reconnecting the USB link PC-ESP the blue led on the ESP is blinking like crazy and on a connected terminal I see a lot of symbols passing. Not working properly but apparently running wild. No way to stop it except power off.
Please suggestions.
Thx
Harry

from esp_wifi_repeater.

This is the typical behaviour with a non-matching version of "esp_init_data_default.bin" in the flash. See above:

"If the firmware files from above flash correctly but after reboot you see only garbage on the serial and/or the LED on GPIO2 is flashing rapidly, try to re-initialize this sector: download https://github.com/espressif/ESP8266_NONOS_SDK/blob/master/bin/esp_init_data_default.bin?raw=true and flash it to 0x7c000 for 512 kB modules (some ESP-01, Sonoff Switch), 0xfc000 for 1 MB modules (most ESP-01), or 0x3fc000 for 4 MB modules (most ESP-12, Wemos D1)."

Did you check this?

from esp_wifi_repeater.

Will try that asp, but could not reach that info; link seems broken. Alternative link?
thx
Harry

from esp_wifi_repeater.

For what it's worth I'm having the same problem and the link isn't working for me either. Anyway clues / tips?

from esp_wifi_repeater.

Try this one: https://github.com/espressif/ESP8266_NONOS_SDK/raw/master/bin/esp_init_data_default_v08.bin

from esp_wifi_repeater.

thanks Martin, but still no joy:

• MyAP doesn't appear
• gobbleygook in the serial monitor - first line: {ll|l|

No errors reported throughout the process and checksums seem ok. FYI, I'm using

• wemos nodemcu devkit board 4MB
• esptool v2.0-beta2
• Mac OS X Sierra

Steps followed:

1. erase flash
2. write firmware/0x00000.bin 0x10000 firmware/0x10000.bin
3. write esp_init_data_default_v08.bin to 0x3fc000

esptool.py --port /dev/cu.wchusbserial1450 erase_flash

esptool.py v2.0-beta2
Connecting....
Detecting chip type... ESP8266
Uploading stub...
Running stub...
Stub running...
Erasing flash (this may take a while)...
Chip erase completed successfully in 24.8s
Hard resetting...

esptool.py --port /dev/cu.wchusbserial1450 write_flash -fs detect 0x00000 firmware/0x00000.bin 0x10000 firmware/0x10000.bin

esptool.py v2.0-beta2
Connecting....
Detecting chip type... ESP8266
Uploading stub...
Running stub...
Stub running...
Attaching SPI flash...
Configuring flash size...
Auto-detected Flash size: 4MB
Flash params set to 0x0040
Compressed 41024 bytes to 27176...
Wrote 41024 bytes (27176 compressed) at 0x00000000 in 2.4 seconds (effective 134.8 kbit/s)...
Hash of data verified.
Compressed 246420 bytes to 170045...
Wrote 246420 bytes (170045 compressed) at 0x00010000 in 15.2 seconds (effective 129.7 kbit/s)...
Hash of data verified.

Leaving...
Hard resetting...

esptool.py --port /dev/cu.wchusbserial1450 write_flash -fs detect 0x3fc000 esp_init_data_default_v08.bin

esptool.py v2.0-beta2
Connecting....
Detecting chip type... ESP8266
Uploading stub...
Running stub...
Stub running...
Attaching SPI flash...
Configuring flash size...
Auto-detected Flash size: 4MB
Compressed 128 bytes to 75...
Wrote 128 bytes (75 compressed) at 0x003fc000 in 0.0 seconds (effective 31.5 kbit/s)...
Hash of data verified.

Leaving...
Hard resetting...

Any tips gratefully accepted!

from esp_wifi_repeater.

Please try --flash_mode dio first.

Also, havn't seen that compression stuff before...? You might try with another flasher like the one I gave in the link.

from esp_wifi_repeater.

Martin, dio did the trick! Thank you. Compression was still enabled and seems ok.

For the record, here are the commands I used
esptool.py --port /dev/cu.wchusbserial1450 erase_flash
esptool.py --port /dev/cu.wchusbserial1450 write_flash -fm dio -fs detect 0x00000 firmware/0x00000.bin 0x10000 firmware/0x10000.bin
esptool.py --port /dev/cu.wchusbserial1450 write_flash -fm dio -fs detect 0x3fc000 esp_init_data_default_v08.bin

Now I look forward to playing with your project. Happy New Year, Hugh

from esp_wifi_repeater.

Hello Martin,
Happy New Year. Thx for the advise: "If the firmware files from above flash correctly but after reboot you see only garbage on the serial and/or the LED on GPIO2 is flashing rapidly, try to re-initialize this sector: download https://github.com/espressif/ESP8266_NONOS_SDK/blob/master/bin/esp_init_data_default.bin?raw=true
Adding that to the two binary files and downloading them all together in dio mode via usb to my ESP 8266 12E got it working. I tested and reconfigured it via an Arduino IDE serial connection from my Win 10 PC. The soft AP (MyAP) appeared on my scanner (Android). Via ‘scan’ command on the Arduine IDE terminal I could also find other networks to.
But to my regret I could not connect tot MyAP via IP in a browser and also not via my Sonoff ESP device(s) so far (they have Tasmota software on them with mqtt capabilities enabled: host = MyASP and port= 1883). See the printout of the Sonoff unit info below.
Maybe I still have to configure something on MyAP and/or on the Sonoff unit?
Another issue is that after a few 'power of of the ESP 12E with MyASP on it, the Wifi connection of it remains in a try situation (led blinking now an then. May be a config issue; should it be locked to be sure?
Appreciate your suggestions very much.

from esp_wifi_repeater.

Hello Martin,
I am very happy with your ESP-mqtt solution in combination with the Homevision Controller (HV) and Ron Bostons HV plugin for mqtt. The next challenge is a direct serial link between the ESP and the Homevision Controller (commands and feedback). The script below is intended for feedback from ESP to HV.
But so far I could not load it in the ESP via a connected Arduino Ide on a Win 10 PC.

1. Tried first to use the web browser link of HV where the scrip resided:
   CMD>script http://192.168.1.6:11080/script.txt
   HTTP request to http://192.168.1.6:11080/script.txt started
   CMD>
2. Secondly a download from Github (same script, facilitated by Ron Boston):
   CMD>script https://raw.githubusercontent.com/........../script.txt
   HTTP request to https://raw.githubusercontent.com/........./script.txt started
   CMD>client handshake start.
   client handshake ok!
   client's data invalid protocol
   Error: SSL error 3
   =====
   Can you help Ron Boston and me out on the following issues:
   A: a way to get the script correctly loaded into the ESP via the Arduino ide
   B: review the script on possible mistakes that prevent it form loading/functioning.
   Kind greetings
   Harry Hendriks

script.txt:

% Config params, overwrite any previous settings from the commandline
% config bitrate 19200
% config system_output 0

on init
% Subscribe
do
subscribe local stat/Woonkmr/POWER
subscribe local stat/Buiten/POWER
subscribe local stat/SVTest/POWER
% ... (additional subscribes, one for each of the remaining devices)

% Woonkmr -> flag 32
on topic local stat/Woonkamer/POWER
do
if $this_data = "on" then
println ",>2001"
else
if $this_data = "off" then
println ",>2000"
endif
endif

% Buiten -> flag 33
on topic local stat/Buiten/POWER
do
if $this_data = "on" then
println ",>2101"
else
if $this_data = "off" then
println ",>2100"
endif
endif

% SVTest -> flag 34
on topic local stat/SVTest/POWER
do
if $this_data = "on" then
println ",>2201"
else
if $this_data = "off" then
println ",>2200"
endif
endif

%... (additional similar "on topic"s for each remaining device)

on serial
do
% parse inputs of the form: pub,{topic},{payload}
if csvstr($this_serial,0,",") = "pub" then
publish local csvstr($this_serial,1,",") csvstr($this_serial,2,",")
endif

from esp_wifi_repeater.

Sorry, a recent change to add http requests in scripts has broken the script download via http. This is fixed in the lastest upload.

So, upload the script to a web server and then load it from the ESP using "script your_url" as you tried already.

I checked the script, nearly perfect, i think. Made only some minor fixes and it seems to work for (as far as I can test without a HV):

% Config params, overwrite any previous settings from the commandline
% config bitrate 19200
% config system_output 0
on init
% Subscribe
do
subscribe local stat/Woonkmr/POWER
subscribe local stat/Buiten/POWER
subscribe local stat/SVTest/POWER
% ... (additional subscribes, one for each of the remaining devices)
% Woonkmr -> flag 32

on topic local stat/Woonkamer/POWER
do
	if $this_data = "on" then
		serial_out ",>2001" | #0d
	else
		if $this_data = "off" then
			serial_out ",>2000" | #0d
		endif
	endif

% Buiten -> flag 33
on topic local stat/Buiten/POWER
do
	if $this_data = "on" then
		serial_out ",>2101" | #0d
	else
		if $this_data = "off" then
			serial_out ",>2100" | #0d
		endif
	endif

% SVTest -> flag 34
on topic local stat/SVTest/POWER
do
	if $this_data = "on" then
		serial_out ",>2201" | #0d
	else
		if $this_data = "off" then
			serial_out ",>2200" | #0d
		endif
	endif

%... (additional similar "on topic"s for each remaining device)

on serial
do
	% parse inputs of the form: pub,{topic},{payload}
	setvar $topic_str = csvstr($this_serial,1,",")
	setvar $data_str = csvstr($this_serial,2,",")
	if csvstr($this_serial,0,",") = "pub" then
		publish local $topic_str $data_str
	endif

from esp_wifi_repeater.

Thank you very much Martin.

Downloaded the complete set from github and tried to flash the bin files via the ESP tool for Windows to the ESP826612E.

Encountered problem: accessing the 0x10000.bin file denied. Other bin file(s): no problem to download them in the ESP.

Please advise a solution.

Kind greetings

Harry

from esp_wifi_repeater.

from esp_wifi_repeater.

Finally got to trying this code myself today. I was able to flash (separately ) both of the .bin files without any problem, as well as the third one recommended in the thread. Here's what I did (using an ESP8266-01s):

esptool.py --port COM5 erase_flash
esptool.py --port COM5 write_flash -fm dio -fs 1MB 0x0 0x00000.bin
esptool.py --port COM5 write_flash -fm dio -fs 1MB 0x10000 0x10000.bin
esptool.py --port COM5 write_flash -fm dio -fs 1MB 0x3fc00 esp_init_data_default_v08.bin

These all worked fine, as far as the downloads are concerned.

However, the code does not seem to be working, or I'm doing something wrong myself. I have no serial connection, nor do I see the MyAP wifi.

But at least I didn't have any issue with the flashing itself... :)

Ron

from esp_wifi_repeater.

For an ESP-01 with 1MB of flash esp_init_data_default_v08.bin has to be flashed to address 0xFC000. Guess, this is the problem.

from esp_wifi_repeater.

Ahh, of course! Thanks.

from esp_wifi_repeater.

That worked. Got my ESP up and running, and was able to load the script. Of course, this particular script won'r work for me, but it shows that I could load it via the HVXL webserver.
Thanks.

from esp_wifi_repeater.

Some Progress on my try at this. I have the serial port connected to a Putty connection so I can see what is happening there. Also have the telnet connection to 7777 to do actual console work as we want to have system_output 0. Until I set that, the serial port was also working as a console. Once system_output 0 was set, saved and reset, no output was seen there. Was able to connect my MQTT HV client to the broker and subscribe to a topic. Here's the config and mqtt show:

CMD>show mqtt
Current clients: 1
HVXL85a2c5e5ab850c2c
Current subsriptions:
local: "stat/Woonkmr/POWER" (QoS 0)
local: "stat/Buiten/POWER" (QoS 0)
local: "stat/SVTest/POWER" (QoS 0)
HVXL85a2c5e5ab850c2c: "cmnd/SVTest/POWER" (QoS 0)
Retained topics:
MQTT client disconnected
Script enabled
CMD>show config
STA: SSID:xx PW:xx
AP:  SSID:MyAP PW:none [open] IP:192.168.4.1/24
Network console access on port 7777 (mode 3)
MQTT broker max. subscription: 30
MQTT broker max. retained messages: 30
MQTT broker max. clients: 0
MQTT client disabled
NTP server: 1.pool.ntp.org (interval: 300 s, tz: 0)
Clock speed: 80
Serial bitrate: 115200
System output: none

I can issue a publish from the console and it gets to my HV client OK:

CMD>publish local cmnd/SVTest/POWER on
Published topic

I sent a message from my client to one of the subscribed topics of interest. (This is the main goal of this project.) Saw nothing on the serial port. However, I did add a couple of print lines to the script to show that the message was received and I did see output there. Here's a portion of the script showing the added print lines:

 36: % SVTest -> flag 34
 37: on topic local stat/SVTest/POWER
 38: do
 39:     print "SVTest: "
 40:     println $this_data
 41:     if $this_data = "on" then
 42:         serial_out ",>2201" | #0d
 43:     else
 44:         if $this_data = "off" then
 45:             serial_out ",>2200" | #0d
 46:         endif
 47:     endif
 48:
 49: %... (additional similar "on topic"s for each remaining device)
 50:
 51: on serial
 52: do
 53:     % parse inputs of the form: pub,{topic},{payload}
 54:     setvar $topic_str = csvstr($this_serial,1,",")
 55:     setvar $data_str = csvstr($this_serial,2,",")
 56:     if csvstr($this_serial,0,",") = "pub" then
 57:         publish local $topic_str $data_str
 58:     endif
 59:     println $this_serial

Here's what I saw on the console when I sent it a "stat/SVTest/POWER on" message:

CMD>SVTest: on
,>2201

as expected. But also expected ",>2201" on the serial port, saw nothing.

Tried typing a "pub,cmnd/SVTest/POWER,on" on the serial port, but nothing happened. Didn't get an expected print on the console, nor was the input published as expected.

When the device starts up, this is what I see on the serial port:

d ãrldLj


WiFi Router/MQTT Broker V2.0 starting



Con{cursor}

So I suspect there is something not quite right with the "system_output 0" setting, or, much more likely, something I'm missing to get this to work.

Comments?

Thanks,
Ron

from esp_wifi_repeater.

I tested the script exactly in the described config: "system_output 0", console connected via telnet 7777. Then, after init only serial_out goes to the UART. But then your script should NOT print the ",>2201" to the console but only to serial. It does for me...

An input string on the serial has to be termininated with an CR character, try to enter CRTL-M after the pub command.

from esp_wifi_repeater.

Then I must have something else set wrong. I keep getting serial_out sent to the console, not the serial port.
For sending out through the serial port, I tried CTRL-M, but no success there either.

I've restarted several times, but same thing every time. I'm at a loss to explain why it works for you but not me!

from esp_wifi_repeater.

Here's my complete script. The print/println are there for debugging. I change system_output manually via the console. then save/reset

% Config params, overwrite any previous settings from the commandline
% config bitrate 19200
% config system_output 0

on init
% Subscribe
do
subscribe local stat/Woonkmr/POWER
subscribe local stat/Buiten/POWER
subscribe local stat/SVTest/POWER

% ... (additional subscribes, one for each of the remaining devices)
% Woonkmr -> flag 32

on topic local stat/Woonkamer/POWER
do
    if $this_data = "on" then
        serial_out ",>2001" | #0d
    else
        if $this_data = "off" then
            serial_out ",>2000" | #0d
        endif
    endif

% Buiten -> flag 33
on topic local stat/Buiten/POWER
do
    if $this_data = "on" then
        serial_out ",>2101" | #0d
    else
        if $this_data = "off" then
            serial_out ",>2100" | #0d
        endif
    endif

% SVTest -> flag 34
on topic local stat/SVTest/POWER
do
    print "SVTest: "
    println $this_data
    if $this_data = "on" then
        serial_out ",>2201" | #0d
    else
        if $this_data = "off" then
            serial_out ",>2200" | #0d
        endif
    endif

%... (additional similar "on topic"s for each remaining device)

on serial
do
    % parse inputs of the form: pub,{topic},{payload}
    setvar $topic_str = csvstr($this_serial,1,",")
    setvar $data_str = csvstr($this_serial,2,",")
    if csvstr($this_serial,0,",") = "pub" then
        publish local $topic_str $data_str
    endif
    println $this_serial

from esp_wifi_repeater.

OK, I played a little with the serial terminal settings in PuTTY and now I can send out through the serial port!
I successfully sent a "pub" message!

But serial_out still comes out on the console.
In case I had some other setting that was blocking serial output, I checked the FTDI I use to connect the ESP to my PC. It blinks whenever I type IN chars to send ("pub" etc.), but when I should be getting something out, no blinking. I interpret that to mean that the ESP isn't sending anything out the serial port.

Of course, it I configure with serial_output 1, I do get serial output so I know the connections are OK.

So close....

Getting really late here so that's all for me for a while...

Thanks,

Ron

from esp_wifi_repeater.

Ok, see the problem: If publish to "stat/Buiten/POWER" it works, if I do it to "stat/SVTest/POWER" not. Obviously, the println before disturbes that. Should not happen and I will look into that.

But for now, it should be enough to remove the debug output. Does this work for you as well?

Publishing also works for me: blindly typing "pub,1,2" on the serial gives me a publication (with the trailing CR in the data, but I will remove that in the next version)

from esp_wifi_repeater.

Yes! Now I think we have it!!!! Not sure why I didn't see the received data before I put in those print/println lines. I put them there because I wasn't seeing anything, but I guess "user error" at that point. :)

In my client, I do notice that extra character in the published message.

Thanks for you help and patience.

Really going to sleep now...

Ron

from esp_wifi_repeater.

Good night! ;-)

Think, I fixed the two issues now:

• serial input waits for NL terminated strings,(it is actually not CR), cuts of the last char, and hands it over to the script
• serial_out should not any more mix up with prints

from esp_wifi_repeater.

Martin and Ron,
Thank you both very much for this progress via excellent joint cooperation and as a result giant steps forward. I will do my best to catch up. But regretfully i am not in the same league of IT literacy.
Kind greetings,
Harry

from esp_wifi_repeater.

Loaded your latest version. Looks like the extra char removal works fine. Now it doesn't confuse my client! :)
Haven't tried adding back in any prints near serial_out yet.

Thanks for the quick fixes!

from esp_wifi_repeater.

Be aware that the | #0d (CR) I put after each serial_out are just for printing on the terminal:
serial_out ",>2000" | #0d

Maybe you want to remove them, if you parse it with the HV...

from esp_wifi_repeater.

OK, thanks. HV expects incoming lines to be terminated with a CR (0d) so I think it will be fine as is.

We'll see for sure once Harry gets his system up to the tests I've done so far and we then take the next step of connecting the ESP to the HV hardware instead of PCs.

from esp_wifi_repeater.

HI
Things are going quite well. We're making progress!

We did run into a small issue that prompts a scripting question:

We have several different devices that may return any of "on", ON", "On" as on responses. I don't see a script way to compare with "nocase" so I think we need to handle the alternatives like this

    if $this_data = "on" then
        serial_out ",>2001" | #0d
    else
        if $this_data = "ON" then
            serial_out ",>2001" | #0d
        else
            if $this_data = "On" then
               serial_out ",>2001" | #130 
            else
               if $this_data = "off" then
                  serial_out ",>2000" | #0d
              else
                  if $this_data = "OFF" then
                     serial_out ",>2000" | #0d
                 else
                     if $this_data = "Off" then
                        serial_out ",>2000" | #130 
                    endif
                endif
            endif
         endif
      endif
  endif

Which is nested ifs six levels deep. Not sure how far the scripting can go.

I could also just do

    if $this_data = "on" then
        serial_out ",>2001" | #0d
    else
        if $this_data = "off" then
            serial_out ",>2000" | #0d
        endif
    endif

one after the other for each spelling variation to avoid the deep nesting.

Just wanted to check to make sure I didn't miss something that would make this a little more compact.

Thanks.

from esp_wifi_repeater.

Actually on second thought, Since each topic only applies to one device, we can just customize for what that devise puts out. So we can stay with the original design, just changing what to look for.

But I'm still curious about nocase and nesting levels...

BTW, I think this thread is probably in the wrong project. If we have further questions, maybe we should start new threads under ESP_MQTT?

from esp_wifi_repeater.

There is no build-in limitation on the number of nesting leverls other than stack size. Nested if-thens are interpreted recursively. In than sense less is better as mem size is an issue on the ESP anyway and espexially for the broker.

You are right, we should move to the esp_mqtt repository, It started here as this came to life as a branch of the repeater, but now it is a stand-alone project.

from esp_wifi_repeater.

Hi all,
After quite some tinkering and testing the ESP-mqtt/bridge of Martin is now also working in combination with the Homevision (HV) Automation controller via a direct serial link (RS232).
Many thanks go to Ron and Martin (resp. rebel 7050 and on Martin-Ger on Github) for their efforts.
Martin provided the broker/bridge software https://github.com/martin-ger/esp_mqtt and also accurately and quickly advised about how to adapt this to the Homevision needs.
Ron previously, amongst other things, designed the HV mqtt plug-in: (https://github.com/rebel7580/MQTT-Plug-in-For-HomeVisionXL).
For this new ‘stand alone concept (HV+ ESP)’ Ron detailed the specific requirements and wrote the required software for HV and the ESP 8266 (a script). It was tested by Ron and me together.
The HV serial port 2 is now directly connected to an ESP 8266 via an DB9-ttl conversion module and via that link mqtt commands are sent to a number of Sonoff wifi units via the ESP broker. The executed commands are confirmed back as status info. HV evaluates this and sets flags accordingly.
Previous all wifi actions were relayed via a PC with HV software on it (like the mqtt plug-in).
The main advantage of the new setup is it simplicity and reliability and it also extends the useful lifetime of HV. No upstart problem anymore after a power failure and/or when the monitoring PC fails (this will happen if used 24/7). The beauty of the new solution is also that Rons Wemo and mqtt plug-in for HV are also still working and do not conflict with this new solution.
May be this new solution is not only interesting for HV users but can also help other persons who like to link their home automation equipment to an ESP 8266 a9ai used a 12E ).
I assume that Ron and Martin will provide the more technical information on the /their Github pages.
I admire their expertise very much and will be a happy user of this/their creations.
Kind greetings,
Harry Hendriks

from esp_wifi_repeater.

Very happy to read, that the broker is useful for this project.

Thank you for you work and your trust in mine. ;-)

Will close this issue here. I would suggest to continue any further discussion under https://github.com/martin-ger/esp_mqtt

from esp_wifi_repeater.

from esp_wifi_repeater.

Look into: https://github.com/martin-ger/esp_mqtt

from esp_wifi_repeater.

from esp_wifi_repeater.