New (old) project...

[M*I*B]

Or use ESPEasy plugin P044 P1 WiFi Gateway, that can be installed multiple times.

I have just take a look... But where can I chose the GPIO that the GW have to take data from? There is nothing about to see...

Bild_2023-01-03_164517428.png (21.31 KiB) Viewed 3539 times

... but I'm sure that I just overview some .. or not?

[Ath]

Please download a build from the PR I linked, most recent is this Github Actions run (Edit: just started a new run)

[M*I*B]

... ahh ok... I never get that gittyhubbystuffstaffstiff ^^

BTW and full off topic:
Do any of you know with which simple CAD freeware you can draw a scale for an old analogue instrument???
I've just tried it with LibreCAD, but I'm already unsuccessful in dividing the dividers. There is no function for this, e.g. to generate exactly 9 ticks with a length of 15mm on a 90° circle segment...

See also viewtopic.php?p=62052#p62052

[M*I*B]

EDIT 2:
This board is useless for that. A pull-up from V+ to PWM is simply missing for each port.
It is a mystery to me why these servos should supposedly run on all the whole internet sides without any further measures being taken; definitely not possible without PullUp ...
Incidentally, the "Extra IO - PCA9685" is not well suited for servos. It's not meant for that, is it? For example, if I set the frequency to 50Hz = 20ms (60Hz is also possible) and select a range of 100, then I can move the servo from 89-97, corresponding to a rotation angle of around 180°.
If I set the range to 1000, I'm left with the range from 885 to 975
EDIT:
Seems to be a problem with the servos. PWM comes out of all but all three servos don't work. Two of them are brand new, one is used... but it can't be that all are broken...



Ok, today the PCA9685 PWM crash into my postbox.

I have connect them and also 3 servos at PWM 0, 4 and 15. Also I have set all as default at "Extra IO - PCA9685" (0x40, shown in the "I²C-Scan", 0x10 for mode2) except the frequenz for mode 2 that I have set to 60

Now I send i.e "pcapwm,0,2000" but they do nothing...

What I'm doing wrong?

Bild_2023-01-04_184203705.png (10.31 KiB) Viewed 3509 times

EDIT:
Thing is also that an address 0x70 show up if I connect the PWM; have try this also with no response except that the 0x70 address is gone if I try to use it

Bild_2023-01-04_185132017.png (14.09 KiB) Viewed 3508 times

Bild_2023-01-04_190248173.png (519.83 KiB) Viewed 3506 times

[TD-er]

Yesterday I did type an elaborate post about the specifics of a servo. So I just link it here
viewtopic.php?p=62217#p62217

TL;DR
Servo's need quite a specific timing sequence.
So maybe you should test the servo's first on a GPIO pin on the ESP using the servo commands.

[M*I*B]

... funny twin - ways

BTW: Unfortunately, that destroys my idea of removing (and storing) the moving-iron movements of the retro instruments and replacing them with servos.
Then, for better or worse, I will have to wrap all the coils so that they reach full deflection with 4.5V...

[M*I*B]

Ok, last for now...

I have read a while at the datasheet https://www.nxp.com/docs/en/data-sheet/PCA9685.pdf. Special side 14 and 16 are very important. I start with side 16.
There I find out that 0x10 can't be the default due BIT 2 of ModeRegister 2 default are 1 (TP on output) but the outputs are set to OD with 0x10. So if you set the Mode2 to 0x04 or 0x14 (inverted output) the servos walk without an external pullup...
That's the 1st one.

The 2nd one is how to touch ModeRegister1 (see side 14)?
I don't can call all servos via "all" and also not via "sub". So I can't initialize all servos at startup and have to touch every single port step by step.

then for all my servos (6 different types) ...
M2 = 0x04 & Range = 10000 --> pwm from about 340 to about 1210 works for 0° to 180°-190°
M2 = 0x14 & Range = 10000 --> pwm from about 8890 to about 9760 works for 0° to 180°-190°
So it comes to 180/870 steps while ignoring the low resolution of 12bit

... and ...
while running the testloop rule to check out these ranges the esp sometimes crash and reboot...
Power source for servos are a 6V12AH PB, VCC for PCA9685 PCB and ESP are independent (ESP from PC, 2A USB / PCB from labor PSU)
Script is simple to test stability ...

Code: Select all

on System#Boot do
	LoopTimerSet_ms,1,3000
  Let,1,0
  PWM,12,500 # for LCD2004 back lite
endon

// Let the LED blink if Task "Regler" disabled
on Rules#Timer=1 do
    TaskValueSet,2,1,8900
    TaskValueSet,2,2,9625

  If %v1% = 0
    pcapwm,0,[Range#HI],200
    pcapwm,1,[Range#HI],200
    pcapwm,11,[Range#HI],200
    Let,1,1
  Else
    pcapwm,0,[Range#LO],200
    pcapwm,1,[Range#LO],200
    pcapwm,11,[Range#LO],200
    Let,1,0
  Endif
    endon

[TD-er]

I have not (yet) looked at the code for pcapwm, but given how blocking the "fade" option on the regular PWM command is, I can guess what it will do there.

Better not use those 'fade' options for the PWM commands.
I still need to think about something to make them a bit more useful, since (at least the normal PWM command) does perform an active loop to update the duty value.
We now have a lot more options to schedule task actions, so I guess we must do something like that to perform the fade options.

On ESP32 there are some hardware features to let PWM update over some range, but I have not yet updated the code to actually use those HW timers.

[M*I*B]

yepp, that will be a good one... But former I don't have used fade and then it crashed more often. Seems that fade soften that problem instead of harden ...

Anyway... This PWM to drive a servo don't work as expected right now so I will swap back to my coil winding option. Time to test the counter device to count the winding
At the end there are just eight analog gauges with new dail and eight WS2812B LED- stripes that haven't to update often; only if one value (temp, hum, brightness, gas price, ...) change ...

[TD-er]

Are you actually using servos to move the gauges? or do you use PWM to generate some analog value?

[M*I*B]

... the 1st idea was to use PWM to move the gauges but for that I have to rewind the coils inside. Half of the bunch are Ampere meters witch 3mm copper wire coil (10A full scale, used with shunt), the other are for 100V full scale (400V and 2kV used with serial shunt).
Then I remember that I have many many servos from my RC hobby from micro 3g to big ones with heavy duty steel gear. Then the idea came up of removing the moving iron measuring mechanisms and storing them in their original form and using servos in their place. That would have saved me wrapping and destroying the original measuring mechanisms.

[M*I*B]

Ok... Yesterday evening the programmer/DevSet for the WROOM-32 arrived. I have buy this one: https://www.ebay.de/itm/233809035945?var=533482868761
I have chose this due I have the same for the 8266 and that works very well and it's very good to handle while testing and flashing. Only the placing of the module are a little frickeling ...
So I have flashed the ESP_Easy_mega_20230111_max_ESP32_16M8M_LittleFS Jan 11 2023. Works great and the response of the WebGUI is very fast. And the number of existing devices has killed me at first

So maybe someone have the same flasher... I see some difference between the 8266 and this one.
If I switch off the 8266-flasher the power on the 5V and some other, also the UART stay present. The new flasher is different. If I switch off the ESP32- Flasher, all is off including the USB-UART. That's not so funny...
An other thing what I can't reproduce now is, that if I have pressed the RST the terminal (HTerm) tell me that the ESP32 waiting for download?!? That I have more then twice yesterday. After update the "factory" version with the now running one via OTA I can't reproduce it anymore.
Can anybody confirm my experiences?

Some more:
Would it be possible to use the UNIT number as entered with leading zeros in a future version?
For example, if I now enter "005" in UNIT, it is always converted to "5" and the leading zeros are removed. It is already clear to me why, since no string is certainly used here.
But if you have a whole bunch of ESP's in use and want to use the UNIT-ID as an addition to the host name, that's a bit awkward because it messes up the sorting. Then "ESP-10" usually comes before "ESP-1"... But that's just whining at a high level; I currently set the hostname prefix manually to keep track of things...

[Ath]

Some more:
Would it be possible to use the UNIT number as entered with leading zeros in a future version?
For example, if I now enter "005" in UNIT, it is always converted to "5" and the leading zeros are removed. It is already clear to me why, since no string is certainly used here.
But if you have a whole bunch of ESP's in use and want to use the UNIT-ID as an addition to the host name, that's a bit awkward because it messes up the sorting. Then "ESP-10" usually comes before "ESP-1"... But that's just whining at a high level; I currently set the hostname prefix manually to keep track of things...

That could introduce an option in Tools/Advanced, "Format Unit Number using 3 digits when appended to name" (maybe I'd shorten that a bit )
So that would be applied when the Config page has "Append Unit Number to hostname" checked and when appending the Unit Number in the Controller configuration pages?

From the rules it is already possible to format it properly (though a little bit awkward:

Code: Select all

  Let,199,%unit%
  LogEntry,"Unit number: [var#199#D3]"

)

[M*I*B]

So that would be applied when the Config page has "Append Unit Number to hostname" checked and when appending the Unit Number in the Controller configuration pages?

Yes, that is what I have in mind. If you the looking at your network or scanning and sorting by hostname it will be looks much better then... But it's really a cosmetic thingy... That just came up while looking for the new one in my lan-list that grap an IP from the DHCP and isn't coupled to MAC right now...

From the rules it is already possible to format it properly (though a little bit awkward:

Code: Select all

  Let,199,%unit%
  LogEntry,"Unit number: [var#199#D3]"

)

Ok, that I haven't know... Is a bit from behind through the eye, ha Thanks for that Hint

[TD-er]

Or we could allow system variables to be used in the hostname.
Still, formatting numbers isn't possible using only system vars, or maybe it is but then probably won't fit in the hostname field.

Not sure if we have a "hostname" command which can set the hostname.
If we do, then you can set it each time at boot in the rules using all kinds of substring commands available

About the flashing module.
Not sure how it is wired internally, but it looks like it might pull down GPIO-0 when turned on?

[M*I*B]

I think that's rather counterproductive. The field for the host name and the field for the UNIT number are already there and, in my opinion, in the right place. Why should you then additionally manipulate these values via rules?
I think ATH's idea makes more sense. You could also always append the UNIT number as a standard with 3 digits to the host name. And to ensure compatibility with productive systems, make it deactivatable in the "Advanced Settings" so that it works as before, so that those who address the ESP by host name do not have to change everything after an update.

About the flashing module.
No, I do not think so. At the moment it works yes; I can no longer reproduce it with the download, neither with the reset button nor with the switch.
What I meant more is whether there are perhaps other identical flashers that are wired differently. Because the power switch turns everything off completely, in contrast to the 8266 flasher. And that's stupid, because then the connection to the computer is also cut off and the terminal program shuts down because the COM port is gone too...

[Ath]

Not sure if we have a "hostname" command which can set the hostname.
If we do, then you can set it each time at boot in the rules using all kinds of substring commands available

There is the "name" command, thus the above would become:

Code: Select all

On System#Boot Do
  Let,199,%unit%
  Name,"ESP-[var#199#D3]"
  Let,199,0 // Reset to default
Enddo

This expects/assumes the "Append unit Number to hostname" checkbox to be disabled!

[TD-er]

I think that's rather counterproductive. The field for the host name and the field for the UNIT number are already there and, in my opinion, in the right place. Why should you then additionally manipulate these values via rules?
[...]

Because you can't think of all options someone may want to fit in checkboxes and selections.
Also from an "easy deployment" schema, it may be very useful to set a single variable at one spot (e.g. unit field, or variable in a rules file) and then set all other settings which may need this at boot.
This way you only have the same rules file for all nodes and only need to change 1 field.

[TD-er]

[...]

About the flashing module.
No, I do not think so. At the moment it works yes; I can no longer reproduce it with the download, neither with the reset button nor with the switch.
What I meant more is whether there are perhaps other identical flashers that are wired differently. Because the power switch turns everything off completely, in contrast to the 8266 flasher. And that's stupid, because then the connection to the computer is also cut off and the terminal program shuts down because the COM port is gone too...

Not sure if there are different revisions of that ESP32 flashing module.
I know there have been different revisions of the ESP8266 version of such a flashing tool.

Disconnecting the USB to serial chip can also be done explicitly since people may otherwise "zap" the USB port on the PC by static discharge?
After all, everything is exposed.

[M*I*B]

Disconnecting the USB to serial chip can also be done explicitly since people may otherwise "zap" the USB port on the PC by static discharge?

Oh, I don't think so! As long as the UART is connected to USB and powered, the levels are defined. But if I switch off the supply voltage of the UART, then, as far as I know, the danger is much greater, since the data lines are then hanging in the air due to the high-impedance inputs of the UART...

It doesn't matter... Was just a question in the round, whether someone uses this flasher and knows a different behavior...

Because you can't think of all options someone may want to fit in checkboxes and selections.

Sure, but there we are different thinker at this topic

[Ath]

I've created PR #4463 that adds zero-filling the unit number as an option. Not available in Minimal builds.

I've put it on the Tools/Advanced page "Zerofill Unitnr appended to hostname" (it won't be used that often, I assume), though we can decide to move it to the Config page.

[M*I*B]

* GREAT *

it won't be used that often, I assume

Let the future decide that

[Ath]

Let the future decide that

Well, unless people report they are using it, we won't know, as one of the 'features' of ESPEasy is that it doesn't phone-home, so we don't have functional usage statistics.

[M*I*B]

... I see it like this:
If it's there and nobody complains, then it was a good decision

[M*I*B]

Ok, back to topic.

Meanwhile I have set two Serial Server as devices. Both only receive. Device1 with HWserial1 on GPIO4, Device2 with HWserial2 on GPIO5.
At the Moment I have placed one IR-Reader provisionally and get every second a result like that:

Code: Select all

400397: EVENT: !Serial#��SY5�3DA�00��V3.0��
400400: EVENT: !Serial#�
400401: EVENT: !Serial#�-0:0.0.0��55(��SY��6035�0����
400402: EVENT: !Serial#�-0:�.�.0��55(0006��3�.�0���93���詍
400405: EVENT: !Serial#�-0:��.�.0��55(000��3.53�ש�
400518: EVENT: !Serial#�-0:��.�.0��55(000000.00�ש�
400522: EVENT: !Serial#�-0:6�.�.0��55(000000.00�ש�
400523: EVENT: !Serial#�-0:�.�.0��55(000��3.53�ש�
400525: EVENT: !Serial#�-0:96.5.5��55(�0��
400526: EVENT: !Serial#0-0:96.�.�55��
400538: EVENT: !Serial#55(��SY��6035�0����
400540: EVENT: !Serial#!�

This looks similar to what I expected, except the unknown signs. SO I have play around with the settings, but the funny thing is, that I can change the communication parameter from 7 to 8 bit, one or two stop bit... Nothing change ???

An other problem is: How can I grab that with FHEM? I have set that the device have to send it to the FHEM-controller but FHEM ignore that...

Or do I just use the wrong device for that?

[TD-er]

Not to kill the mood here, but my objective to this is that adding a lot of formatting checkboxes and options will not only increase build size, but also make it really hard to keep the user interface intuitive.
Another reason why it may not be intuitive is that it can be excluded from builds with LIMIT_BUILD_SIZE. So a user needs to have 2 types of configuration for both types of builds.
N.B. almost all ESP8266 builds nowadays are of type LIMIT_BUILD_SIZE.

So if a user needs a very specific layout, you know for sure it won't match all kinds of checkboxes. etc.
And then the option to set the hostname using a single command is the only option left.
But this option was already present right now to use the rules.

There is another tricky issue with leading zeroes.
If you add leading zeroes to the %unit% variable, you will run into issues where it may be used as leading zeroes indicate it to be in octal notation.
In ESPEasy the number parsing explicitly ignores octal notation, or at least in the functions where we call our own formatting functions.
But it is not guaranteed that all occurences where a string is turned into an int is using these functions as it is very common to call the .toInt() function from a lot of classes, like the one in the String class.

If you add a checkbox to add leading zeroes, then it is already easy to assume this is done on the %unit% variable.
But this is for sure behavior which may lead to strange behavior as I described above.
If this is not the intention, then you already need to make it explicit in the text next to the checkbox, proving my point this may make it really hard to keep the user interface "intuitive".

I have not yet looked at Ton's pull request, so no idea if he came up with something really intuitive.

[M*I*B]

Ok, it took me a while to fully understand your text.
I mean it's just a matter of appending the leading zeros to the hostname. The %unit% variable should remain unaffected by this.
I'm not a programmer, but I think a small checkbox and a line of code to add zeros if necessary should only take a few bytes... Or am I wrong?

Bild_2023-01-14_194536254.png (9.05 KiB) Viewed 3322 times

[Ath]

Any leading zeroes are only added when appending the %unit% to the hostname (function Settings.getHostname()), so it won't be in the actual %unit% variable.
When applied the length of the %unit% part will be 3 (005 in your example)

[M*I*B]

so it won't be in the actual %unit% variable.

ThumbsUp

Meanwhile I have connect RealTerm by LAN to the ESP.
If I set there ASCII and 7bit I really got what I expected; take a look:

Bild_2023-01-14_200942288.png (12.59 KiB) Viewed 3317 times

Start is ever / followed by the hardware-ID and firmware rev.

1. Unique ID of the meter
2. Cumulative since 1st start
3. L1 actual power
4. L2 actual power
5. L3 actual power
6. Cumulative all phases actual power
7. No idea what 80 means
8. Meter ID again

So the question is how to send that to FHEM or, as option, to MQTT ??

EDIT 1:

Code: Select all

On !Serial Do
  Publish,%sysname%/Status/%eventvalue%
Endon

... works but send and overwrite the former send message. All lines comes in the same topic

So I have to grab line by line and change the topic for every line. I'm thinking about a counter.. Or is there an other option? Lost the red line right now

[Ath]

Please try a build from this PR #4283, that a) offers more options for P020 SerialServer, and b) merges in the (P044) P1 WiFi Gateway, that knows a bit about the P1 protocol you are receiving here.
The a) part includes optionally sending each line as a separate value to controllers

[M*I*B]

... ahem
I read and search and ... but I have no idea how to handle things are showed at the page you have linked

[Ath]

... ahem
I read and search and ... but I have no idea how to handle things are showed at the page you have linked

2 options:
1)
- You can expand the Show all checks link near the bottom of the page
- Select one of the Details links
- Select the Summary option near the left top of the page
- Find the Binaries file in the Artifacts section in the center of the page
2)
- Find the Actions build for the last Pull request build
- Find the Binaries file in the Artifacts section in the center of the page

Either option continue here:
- Download the Binaries.zip file
- Extract the .zip file for the build(s) you want to use
- From that .zip file, extract and upload the .bin file either via OTA or, when using a flash tool, the factory.bin for ESP32 or the regular .bin for an ESP8266 build
- test the new build

[M*I*B]

... not funny *sniff, sniff*

2 options:
1)

... I would have been able to find this way at best by chance

Got it!
Loosely based on "Jim Button": Ahhh! An island with two mountains ... https://youtu.be/jiMmZTl4zdY (need proxy / vpn maybe ... fucking DSGVO)

[M*I*B]

Ok, have the latest running.
But sorry... I have no idea what I have to use to transfer the data at GPIO4 to FHEM
We have the WiFi-Gateway, the Serial-Proxy and the Serial-Server. I have try all of them but I have the feeling that I don't understand which module does what or whether I even have to combine two modules here...
Normally, FHEM sees a new device immediately and integrates the transmitted readings directly via AutoCreate. It doesn't seem to work here somehow... Or I only understand "Bahnhof-Kofferklau'n" again


OT:
I use mostly hTerm for configuring the ESP after flashing via serial. For that I have set a ASCII- file where all my credentials are stored so I can send it with one click. This looks like that at the moment:

Code: Select all

WifiDisconnect
WifiKey,<mysectret>
WifiSSID,<mySSID>
WifiConnect
Rules,1
TimeZone,60
UseNTP,1
Reboot

All the commands I grab out here: https://espeasy.readthedocs.io/en/lates ... mmand.html
What I'm missing is that I can't set the IP for NTP and also not the Latitude and Longitude.
I'm just blind that I haven't find the correct command or is that not implemented right now?

[igorka]

Indeed there is no %i1% notation and to be honest, I don't know why not....
It would make sense to use an integer value for indexing like this: [var#%i1%] instead of [var#%v1%]
But that's about the only really use case I can think of where the [int#X] notation cannot be used and integers are needed.

I apologize for my stupidity . I'm a difficult student, I'm ashamed . I can not understand why the result of floating point calculations? After all, I indicated that the variables have the format int16_t -32 768 ... 32 767. I need all calculations to be integer. And a follow-up question, is it possible to create a variable of type "byte" uint8_t and uint16_t 0 ... 65 535, etc.?

Code: Select all

let,1,100
let,1,12
let,1,[int#1]/[int#2]

result 8,333 but not 8.

[TD-er]

Code: Select all

let,1,100
let,1,12
let,1,[int#1]/[int#2]

This will store it in variable #1
If you query it via [var#1] the result will be a floating point value.
When querying it via [int#1] it will be cast to int.

You can also format it using the floor operator: https://espeasy.readthedocs.io/en/lates ... sformation
But then you probably need to use the var type instead of the int, otherwise you might see funky results when the result of the division has a decimal > 0.5

[M*I*B]

... ok ... Not funny that someone hijack my thread...

[Ath]

OT:
I use mostly hTerm for configuring the ESP after flashing via serial. For that I have set a ASCII- file where all my credentials are stored so I can send it with one click. This looks like that at the moment:

Code: Select all

WifiDisconnect
WifiKey,<mysectret>
WifiSSID,<mySSID>
WifiConnect
Rules,1
TimeZone,60
UseNTP,1
Reboot

All the commands I grab out here: https://espeasy.readthedocs.io/en/lates ... mmand.html
What I'm missing is that I can't set the IP for NTP and also not the Latitude and Longitude.
I'm just blind that I haven't find the correct command or is that not implemented right now?

Shouldn't there be a "save" command just before the reboot? AFAIK, a "reboot" doesn't (nor shouldn't) do a "save" automagically...

There is a command "NTPHost[,<ntp-host-ip-or-url>]", that is missing from the documentation
I'll fix that omission.

Haven't found commands to set the Latitude or Longitude, I'll see if these can be added.

[M*I*B]

Shouldn't there be a "save" command just before the reboot? AFAIK, a "reboot" doesn't (nor shouldn't) do a "save" automagically...

...ooooppsss ... You are right

There is a command "NTPHost[,<ntp-host-ip-or-url>]", that is missing from the documentation

Ahh ok... Then of course I can look for it for a long time Thanx for that

Haven't found commands to set the Latitude or Longitude, I'll see if these can be added.

Is not important. But I thought that if you already set your standard data via SER, then that would go well with it...

[M*I*B]

Ok... I'm lost I have spent the whole day to catch any result.. but failed ...

All I have read is that the Serial-Proxy is that what I have to use. And the SP sent all then to i.e. MQTT...
The only what I got is that:

Bild_2023-01-15_184930139.png (5.92 KiB) Viewed 3121 times

So I have play around with all I get in mind but no result...

So I need a little help what I have to type into the proxy fields to get my data.
As you can see at viewtopic.php?p=62493#p62493 there is not so much. At the end I need readings "DV, CN, L1, L2, L3, LC" filled with the data between the starting ( and the 1st * or ) from the 1st 6 lines starting with "1" so as result I got ...

Code: Select all

DV = 1ESY1160351021
CN = 00067235.3164083
L1 = 001493.72
L2 = 000000.00
L3 = 000000.00
LC = 001493.72

So how to????? I'm running out of ideas ...

Bild_2023-01-15_185118498.png (110.32 KiB) Viewed 3121 times

[Ath]

AFAIR, FHEM has a plugin/module to read a P1 meter via the network, and ESPEasy has a P1 WiFi gateway that can receive that P1 data via serial and send it out to a network client. That way the processing is done at the FHEM side, and not at ESPEasy as that has less resources available. Feels like a better solution direction to me.

[M*I*B]

... yes, you are right, but that only works with a physical connected serial (https://fhem.de/commandref_modular.html#SmartMeterP1)

[M*I*B]

... ok, the only way seems to be to create a virtual ttydev at the machine where FHEM is running. So that's Debian...

I try " socat TCP4:192.168.1.226:4321 /dev/ttyEM1,raw,echo=0" and have think that cocat creates the given virtual port ttyEM1 but that don't work.
socat PTY,link=/dev/ttyS10 creates a virtual but isn't persistent...

So maybe someone here know how to create a virtual tty on a debian that I can use with socat or other stuff/apps like FHEM???

I have also try TruePort from "Perle" under WIN10x64. That works great. Just create a virtual COM20, configure it after creating and connect them to the ESP and let hTerm use com20... very smart! That's really what I need under debian...

[M*I*B]

Ok, that doesn't work on the one hand with socat or ser2net, on the other hand neither with serial server, serial proxy or P1 gateway in any combination...

I give up and scrap the project... It's a complete waste of time...


And BTW: P1 Wifi Gateway don't work in the last build. They don't send/get data from the same port the Serial-Server have no problems with.

Test:
Create a device "Serial-Server" and a device "P1 Wifi Gateway".
Set the 1st to HWSerial1 <-GPIO4 and i.e. port 2221, the 2nd to HWSerial2 <-GPIO4 and Port 2222 (or verse visa).
Provide data to GPIO4
On Windows open i.e. RealTerm twice
Set RT1 to ESPIP:2221 and RT2 to ESPIP:2222
Result:
RT1 show the data on GPIO4 via SerialServer, RT2 via P1 WiFi don't

Change ports and HWSerials if you like or try it one by one... The result is ever the same

realterm_bpxyOGnT2p.gif (148.26 KiB) Viewed 2926 times