This was originally requested in Issue #21 by mkukik.

mkukik: "I've been looking through the code and I came to conclusion that you should consider this: Have just rest api + MQTT on the module and create sample single page external html app that will interact with the rest api. It would be sufficient for debugging purposes or small standalone projects (not as a part of some automation). Usually when you integrate it into some automation you will rarely even use UI. This could significantly simplify and reduce complexity of the code. I could even help with the single page HTML app."

Thanks for a great project, works very well and stable for me.

I'm just wondering if there is an option for the user to rename the button names, e.g. Output1 -> Relay 1 or Light 1 ...

Thanks and good luck

Regards,

Robert

In MQTT builds the RXERIF counter usually has zero in it, but when it starts counting it runs wild.
This issue was found to be the result of failing to clear the RXERIF bit if it is set by the ENC28J60 hardware. The RXERIF counter then increments with each pass of the main loop. A fix has been applied to a test build and is currently undergoing test (Dec 10 2020). This will be released soon, in the meantime the RXERIF counter is unreliable as a diagnostic tool.

Hi nielsonm, i found this https://github.com/dpiegdon/SainSmart-REY-NET-v1.1.
He fixed the MAC Bug also.
Is it possible to merge the your Code that is working with V1 also?

I've had a couple of users ask if the IO pins can be used for analog input. Unfortunately the hardware designer did not bring any of the STM8 analog inputs out to IO pins ... the objective was just a relay controller at the time the hardware was designed. So, analog input is not possible with the hardware as-is.

I did some research and found that there is a 4 channel analog to digital converter that could be attached externally. It requires an I2C interface so would require 2 IO pins to operate it. I found one source on Amazon selling for about $3, but most sellers want $7 to $14. It is a potential solution if there is enough interest. I am not sure it could be included in parallel with the DS18B20 device, so this is just exploratory at this time.

https://www.amazon.com/gp/product/B07QJX4HNP?pf_rd_r=MK9NDZVXP5T5S4K12JJW&pf_rd_p=5ae2c7f8-e0c6-4f35-9071-dc3240e894a8&pd_rd_r=c22460af-fc02-4b59-ace1-f7ba7f3cedc2&pd_rd_w=0HdQd&pd_rd_wg=H3huC&ref_=pd_gw_unk

There is some kind of interaction between browsers when multiple browsers are open. Try this: Open FireFox on IOControl, then open Chrome and access /99. Change an IO on FireFox and click Save. The Save doesn't happen, and the /99 is displayed. I think this is because current_page gets changed and applies to all browser sessions. Current_page is not a per client value ... probably should be. This is probably a non-critical defect because the device should really only be operated by one user with one browser at a time. But it should be fixed to help with the situation when using one browser as a 'monitor' and another function may be using REST commands for automation.

hello if I ask
Can you integrate dht11 temperature and humidity sensor module?

Request is to add a feature that would cause the output to revert to its former state a given number of seconds after a change of state. Perhaps have a byte per output that the user can set to indicate the following action; If output state changes, revert the state after requested number of seconds. This way if the output is normally off, and the user (or MQTT) turns it ON, it will turn back OFF after 1 second (or 2, or 3, etc depending on the setting). Reverse would also be true if the output is normally OFF.

Hello!
If you set the "HA Auto" flag, then when you save the configuration, the "MQTT" flag becomes set, and while "HA Auto" is enabled, "MQTT" will not be disabled in any way.
Is this the way it should be, or is it a mistake?

I have spent some time on MQTT Discovery.

Here are required topics and payloads.

I think we need to use mac address as a key here and device name from configuration in human readable fields.

The hardest thing here is buffer size. Will this JSON payload fit? Spaces and line breaks certainly need to be removed.
Device(dev) part repeats for all inputs and outputs.

Switch (Output)

Topic: homeassistant/switch/<mac>/<##>/config
Payload:

{
  "uniq_id": "<mac>_output_<##>",
  "name": "<device> output <##>",
  "~": "NetworkModule/<device>",
  "avty_t": "~/availability",
  "stat_t": "~/output/<##>",
  "cmd_t": "~/output/<##>/set",
  "dev": {
    "ids": ["NetworkModule", "<mac>"],
    "mdl": "HW-584",
    "mf": "NetworkModule",
    "name": "<device>",
    "sw": "<firmware>"
  }
}

Retained

Binary sensor (input)

Topic: homeassistant/binary_sensor/<mac>/<##>/config
Payload:

{
  "uniq_id": "<mac>_input_<##>",
  "name": "<device> input <##>",
  "~": "NetworkModule/<device>",
  "avty_t": "~/availability",
  "stat_t": "~/input/<##>",
  "dev": {
    "ids": ["NetworkModule", "<mac>"],
    "mdl": "HW-584",
    "mf": "NetworkModule",
    "name": "<device>",
    "sw": "<firmware>"
  }
}

Retained

So in my case config will look like:

Switch (Output 01)

Topic: homeassistant/switch/aabbccddeeff/01/config
Payload:

{
  "uniq_id": "aabbccddeeff_output_01",
  "name": "heating_2floor output 01",
  "~": "NetworkModule/heating_2floor",
  "avty_t": "~/availability",
  "stat_t": "~/output/01",
  "cmd_t": "~/output/01/set",
  "dev": {
    "ids": ["NetworkModule", "aabbccddeeff"],
    "mdl": "HW-584",
    "mf": "NetworkModule",
    "name": "heating_2floor",
    "sw": "<firmware>"
  }
}

Retained

Binary sensor (Input 01)

Topic: homeassistant/binary_sensor/aabbccddeeff/01/config
Payload:

{
  "uniq_id": "aabbccddeeff_input_01",
  "name": "heating_2floor input 01",
  "~": "NetworkModule/heating_2floor",
  "avty_t": "~/availability",
  "stat_t": "~/input/01",
  "dev": {
    "ids": ["NetworkModule", "aabbccddeeff"],
    "mdl": "HW-584",
    "mf": "NetworkModule",
    "name": "heating_2floor",
    "sw": "<firmware>"
  }
}

Retained

In Home Assistant it will appear this way:

Do you have any plans to add support for DHCP?

I have a strong preference toward DHCP reservations on my networks (instead of static IPs), and enjoy the following benefits:
-moving devices quickly between networks for safe troubleshooting
-easier "configure and move elsewhere" situations (as my network is isolated/locked-down for my IoT devices)
-centralized GUI for quick IP view/management
-simpler major network/subnet changes
-remote management via a single CLI for scripting fun

For some users, this feature might also benefit from local discovery (with NETBIOS or Zeroconf) but that is outside the scope of this request, and not something I personally need.

Thank you all the great work!

REST commands are not turning relays on and off. /00 /01 does nothing. Relay power cycle state retention setting does not matter. Likely related to changes made for MQTT logic.

I've been testing by opening multiple browsers of the same or different types from one laptop (one IP address) and this works fine. But opening a browser on two different IP addresses (a laptop on WiFi and a desktop on Ethernet) did not work. They each work fine once the browser is closed on the other. From an initial look at the code this should work OK, so investigation might take some time.

Hello, 1st of all i would like to thank you for effort you made reprograming this useful server. I followed your guide and run into problem. I would try to explain. Server comes online only for few seconds and than its unreachable. I have the feeling that its working very slow and that its going into some kind of loop. One thing i noticed while loading project into STVP is that i get this error no matter what version of code I use (16in, 16out, 8out).

What might be the problem?

FILE : line 952: Address 0x4000 is out of range and is ignored!
FILE : line 952: Address 0x4001 is out of range and is ignored!
FILE : line 952: Address 0x4002 is out of range and is ignored!
FILE : line 952: Address 0x4003 is out of range and is ignored!
FILE : line 952: Address 0x4004 is out of range and is ignored!
FILE : line 952: Address 0x4005 is out of range and is ignored!
FILE : line 952: Address 0x4006 is out of range and is ignored!
FILE : line 952: Address 0x4007 is out of range and is ignored!
FILE : line 952: Address 0x4008 is out of range and is ignored!
FILE : line 952: Address 0x4009 is out of range and is ignored!
FILE : line 952: Address 0x400A is out of range and is ignored!
FILE : line 952: Address 0x400B is out of range and is ignored!
FILE : line 952: Address 0x400C is out of range and is ignored!
FILE : line 952: Address 0x400D is out of range and is ignored!
FILE : line 952: Address 0x400E is out of range and is ignored!
FILE : line 952: Address 0x400F is out of range and is ignored!
FILE : line 952: Address 0x4010 is out of range and is ignored!
FILE : line 952: Address 0x4011 is out of range and is ignored!
FILE : line 952: Address 0x4012 is out of range and is ignored!
FILE : line 952: Address 0x4013 is out of range and is ignored!
FILE : line 952: Address 0x4014 is out of range and is ignored!
FILE : line 952: Address 0x4015 is out of range and is ignored!
FILE : line 952: Address 0x4016 is out of range and is ignored!
FILE : line 952: Address 0x4017 is out of range and is ignored!
FILE : line 952: Address 0x4018 is out of range and is ignored!
FILE : line 952: Address 0x4019 is out of range and is ignored!
FILE : line 952: Address 0x401A is out of range and is ignored!
FILE : line 952: Address 0x401B is out of range and is ignored!
FILE : line 952: Address 0x401C is out of range and is ignored!
FILE : line 952: Address 0x401D is out of range and is ignored!
FILE : line 952: Address 0x401E is out of range and is ignored!
FILE : line 952: Address 0x401F is out of range and is ignored!
FILE : line 953: Address 0x4020 is out of range and is ignored!
FILE : line 953: Address 0x4021 is out of range and is ignored!
FILE : line 953: Address 0x4022 is out of range and is ignored!
FILE : line 953: Address 0x4023 is out of range and is ignored!
FILE : line 953: Address 0x4024 is out of range and is ignored!
FILE : line 953: Address 0x4025 is out of range and is ignored!
FILE : line 953: Address 0x4026 is out of range and is ignored!
FILE : line 953: Address 0x4027 is out of range and is ignored!
FILE : line 953: Address 0x4028 is out of range and is ignored!
FILE : line 953: Address 0x4029 is out of range and is ignored!
FILE : line 953: Address 0x402A is out of range and is ignored!
FILE : line 953: Address 0x402B is out of range and is ignored!
FILE : line 953: Address 0x402C is out of range and is ignored!
FILE : line 953: Address 0x402D is out of range and is ignored!
FILE : line 953: Address 0x402E is out of range and is ignored!
FILE : line 954: Address 0xA is out of range and is ignored!
FILE : line 954: Address 0xB is out of range and is ignored!
FILE : line 954: Address 0xC is out of range and is ignored!
FILE : line 954: Address 0xD is out of range and is ignored!
FILE : line 954: Address 0xE is out of range and is ignored!
FILE : line 954: Address 0xF is out of range and is ignored!

While running an automated MQTT test with a relay ON command every 0.5 seconds followed by a relay OFF command 0.25 seconds later I noted that the Network Module would become unresponsive 5 to 20 minutes after start of the test. Other symptoms: In 3 cases the LED on the modules would flicker continuously; In one case the EEPROM returned to default values (the EEPROM was probably overwritten, and on power cycle it was set to default values since the magic number was no longer present). I also noted that the pattern on the test LEDs (on a debug solderless breadboard) do not always switch uniformly - there can be shorter on periods, gaps, sudden catchups). This last observation could be a problem in the test driver (node-red), the laptop node-red is running on, or due to network delays (laptop is on WiFi).
Investigation: I reduced the relay ON repetition rate to see if it makes a difference. I'm betting I'm just at the processing limit of the Network Module ... but the code should handle this more gracefully. I probably should also lock the EEPROM between writes rather than just leaving it unlocked all the time.

This request from YouTube subscriber Miroslaw Walasik.
The request is to have some form of Real Time Clock and the ability to turn outputs on and off based on Time Of Day when used only with a Browser (ie, no MQTT or upper level timing controllers).
There are a couple of ways to do this: 1) Add an RTC hardware device, 2) Use NTP (which requires internet access). And, of course, it requires the user interface to allow the user to make time settings on a per output basis.
In the spirit of "very low cost relay controller" NTP seems the best way to do this, although I am sure there will be some negative feedback about letting the device access the internet as it has no security features.
I am also concerned that this is somewhat beyond the spirit of this device just due to the amount of user interface required. The GUI is one of the most memory "expensive" aspects of the GUI, so we need to be cautious about this kind of addition.
Still, it is a nice idea if it can be implemented so this issue is opened for future consideration.

Reported by jmcvieira1: Disable all i/o port´s leave mqtt and DS18B20 turned on save and reboot, and the module will not connect to the mqtt server. I have to enable one port to the module connect to the server again.

The REST status page at http://192.168.1.123:8080/99? should be 16 bits long and not have all the extra HTML stuff that needs to be parsed and filtered out as it is not meant for human reading anyway. Just a suggestion.

Report of missing temperature value in MQTT payload. Working on it.

Thank you for spending your time on this great firmware. I have not tried it so far but I am about to start.

Inspecting MQTT topics and see that publishing part is very inconvenient. It would be way better if you'd publish this way:

Getting state

Publish for every change
NetworkModule/<devicename>/pin/<input #>, payload ON or OFF
Same with relay status:
NetworkModule/<devicename>/pin/<output #>, payload ON or OFF
Both retained.

Setting state

NetworkModule/<devicename>/pin/<output #>/set, payload ON or OFF

all could be set this way:
NetworkModule/<devicename>/pin/all/set, payload ON or OFF

Last will

It would be also great to have a last will:
NetworkModule/<devicename>/availability, payload offline
Retained

When device boots it would publish
NetworkModule/<devicename>/availability, payload online and set the last will. Would be good to republish input and output statuses as well. All retained.

Retainability could be configurable, but if you would not retain then there should be a republish interval. Extra effort that has a really low benefit in practice.

This is standard for HomeAssistant.
https://www.home-assistant.io/integrations/switch.mqtt/ for outputs
https://www.home-assistant.io/integrations/binary_sensor.mqtt/ for inputs

Next steps would be to add publishing of HomeAssistant MQTT Autodiscovery configuration. Of course if flash size will allow. This way your firmware will find A LOT of usage in HomeAssistant community. Imagine people just configure MAC Address, IP, MQTT settings and they instantly get the device with all switches in HomeAssistant with zero configuration on HomeAssistant side.

I can help with coding. =)

While it may be atypical to use both the REST commands and IO Control page IO state changes, it should work. However, for the case where IO states are being monitored on the IO Control page, and REST commands /55 or /56 are used, you can't then make IO ON/OFF changes in the IO Control page. This is because the URL bar still contains the /55 or /56 command, and when Save or Refresh is clicked the /55 or /56 command executes again.
This issue has been fixed and will appear in the next release.

Issue #55 and #58 are related, but this issue is focused on Home Assistant and removal of Temperature Sensors when the Network Module power is OFF.
If a temperature sensor is removed while the Network Module power is OFF it does not get deleted in HA. This is because the Network Module doesn't store Temperature Sensor IDs in non-volatile memory. Thus, on power on, the Network Module does not know it needs to send a "delete" message to HA for sensors that were removed while power was down because the Network Module has no knowledge of the serial numbers of devices that are no longer present.
The workaround is to manually delete the sensor entity in Home Assistant, and perhaps that is a sufficient solution. But, of course, it sure would be nice if it was "auto-magic".
To make it work automatically requires storing the serial number IDs of the devices in non-volatile memory. That won't fit in EEPROM, but they could be stored in Flash. This would require making sure unnecessary writes to Flash do not occur since it has a very limited write life cycle.
I think this needs to be shelved for the moment due to concerns about Flash wearout, but I will revisit it in the future.

hi, thanks for the project first of all!
i used the first release, and now i want to update with latest one.
but with latest version i'm not able to find:
NetworkModule.stp - The STVP project file
NetworkModule.sx - The NetworkModule binary file

i had in previous version but i do not see anymore inside project folder, i'm wrong?

thanks!

second question, do you think that it's possible to implement a way that after first flash with your software, it will be possible to update the software without flashing again with USB programmer ST-Link V2 but using web page?
thanks again

This is similar to issue #55.
Issue #55 deals with how to handle a missing temperature sensor at reboot. But the question arises of how to deal with a missing sensor during runtime. The code could be modified to check for sensors that disappear (or a sensor gets added) during runtime as opposed to just at boot time. It makes sense that a sensor that gets added without a reboot could generate a define message to HA. But it is less obvious as to what should happen if a sensor disappears ... generate a delete message to HA? Right now we are thinking that is the correct course of action, but this is open to comment.

Hello Nielson,
on verson 0.118 of HA i had programmed output with success but i was not able to read any inputs
The folowing code configuration.yaml works well:
switch:
platform: command_line
switches:
 ######################################################

IP 192.168.105.105 config

server_off_outlet_01:
command_off: curl http://192.168.105.105:8080/00
friendly_name: 'Server Off 105 n°: 01'
server_on_outlet_02:
command_on: curl http://192.168.105.105:8080/01
friendly_name: 'Server  On 105 n°: 01'

I am now on the last version and i would like use MQTT and HA auto discover.
Unfortunatly i am not good enought to progam.

Can you please show me (and for most of begginers) how to do with real code and the place they have to be.
for examples the configuration.yaml code if needed, with the new HA configuration,
how to read HW-584 datas and temératures on binary sensor or switches.

On my MQTT status only 3 are green and i have no idea how tu setup them.

PS: HW-584 flashing code instructions was clear and details, so that was easy to do.
If needed i can let my email if it is allowed on this site

Regards

Try this: Using Firefox delete the last character of your MAC address, then click Save. A "Please enter requested format" message appears. Now scroll the page up an down. The "Please enter requested format" popup does not stay attached to the MAC field.

If you do this same thing in Chrome the "Please enter requested format" popup stays attached to the MAC field.

I didn't try other browsers.

Timers are not working if the Invert setting is turned on.

Output states are adjusted for the invert bit before storing in the IO16to1 registers. Input states are adjusted when the IO16to1 registers are read. Code size reduction can be achieved and code clarity improved if the input states are inverted before storing in the IO16to1 variables as the input state inversion currently happens in three places when the content of IO16to1 is used. This is a non-critical issue as it doesn't affect the user, but makes it more difficult for code maintenance.

From Sky-Jumper: Is it possible to add the contents of the "Name" field to the <title> tag so that the browser tabs can see which module is open (for example, instead of "IO Control" write "{Name} IO Control")

Automatic recovery from errors seems to work correctly, but the error count does not always appear to update. This is not a critical error, but should be investigated. Awaiting arrival of Cisco business level switch to test in greater detail.

Code Revision 20210221 1826 - is ok, next version not (hangs if I press this button)

When adding and removing temperature sensors the definitions in Home Assistant do not update properly. It appears that sensors that are removed do not get deleted in Home Assistant via Auto Discovery.

A user asked if I had seen the Network Module going unresponsive after a couple of days of operation, and at the time the question was asked I had not seen that. But now I think I've seen it twice on my test bench, so I will be trying to figure out how to track this down. Cycling power puts it back online.

If anyone else is seeing this please let me know. I don't know if it is firmware or if the hardware is having an issue. My test modules have been "abused" with lots of reprogramming cycles (hundreds, if not low thousands of cycles), so I don't know if I am seeing the effects of wearout.

The Help pages skip a number for the REST commands used for relay output control.

I am wondering... can you elaborate on why 16OUT + MQTT isn't possible?
I did notice you saying it in video and mentioning in doc, but I am wondering if there is much to be done to achieve this.

BTW: beautiful project, I have this board for years, but never got to use it due to its awkwardness... just ordered more of 8OUT.

Hello i´m using four sensor´s DS18B20 to monitor temperatures on a two door refrigerator, and came across with
some spikes in the graphic on domoticz but only on negative temperatures, i will try to explain when reading negative temperatures for example
-21,8 next -21,9 next it should red -22 but it jump´s to -21 only to jumping again on the next reeding to -22,1, first i thought it was a sensor problem with the low temperatures, but i change the sensor and the behaviour is still the same, this symptom only occurs in temperatures bellow 0º Celsius, i´m using Code Revision 20210413 1254 with nodered to translate the mqtt messages to domoticz.
Does anyone came across with something like this?

Reported by user Jose: "REST commands for 00 to 31 stopped working with latest release. All others work OK."

I found and fixed this. The fix will come out within a few hours.

Right now temperature sensors are ordered according to their serial number.

But if a temperature sensor fails or is removed, this causes the remaining sensors to shift left in the order. And if that same sensor is repaired the sensors shift right into their original "serial number order". The shifting is confusing to the user and to automation.

Further, if a sensor fails and is replaced with a new sensor that has a different serial number it could end up anywhere in the serial number based order.

Is there a way to maintain the order of the sensors if one becomes intermittent?
And is there a way to allow the user to replace a sensor and force it to be in a given "slot" even though it may be out of order from a serial number perspective?

Initial answer: "Slots" for the sensors can be maintained in a table in Flash. A sensor that has gone missing can report a far out of range temperature like -185C, something obvious to the user as a missing sensor.

Being able to force a given order to the sensors that is not based on serial number ordering is more problematic. It would require some additional GUI interface - an item that is very expensive from a memory perspective. This will require some thought.

Such a problem:
There are two boards, one is configured for 16 outputs with inverted outputs, the second for 16 inputs, in the settings I completely cleared the MQTT Server address and login / password on both boards and saved the settings.
It turned out like this:
The board configured as 16 inputs is no longer on the network, the IP scanner does not find it, after resetting to the factory settings, it worked, set the IP address 192.168.0.250, saved everything to the input, saved it, the board again does not find it, it turned out in this order - set everything to the input, saved, and only then configured the IP address;
Board configured as 16 outputs: in the "Name" field it was "Relay_16" became "0 (Windows NT 10.0;"; in the "MQTT Server" field before clearing the field it was "192.168.2.250" became "192.168.2.88"; the "MQTT" field Username "should have become empty, but the old value remained; the" MQTT Password "field should have become empty, but it has" age = 0Upg "

Hi,

Changed my IP to 192.168.1.123 and trying to change states of one relay output. It changes fine when using your web interface, but when calling http://192.168.1.123:8080/00 and http://192.168.1.123:8080/01, your web IO status shows the change, but the relay doesn't change state? I have to click "Save" on the IO config page.

Hello,
I use some of these pretty nice boards with your firmware because I am a fan of wired devices.
Your firmware is working better from update to update.
The only issue with the updates is that I build in the board and the relay into power strips which are not easy to disassemble.
Would there be the possibility to update them over the webinterface like the tasmota sockets?
That would make it much easier than with the stm flasher.

Reported by Jose: "REST Command´s /98 or /99 are not reporting the ON/OFF status of the port. They are responding to the Type of the port. Using Code Revision 20210126 0527"

While the DS18B20 sensors are not highly accurate to start with, it looks like the firmware adds another +/- 0.1 degree C of variation. Need to determine if the code is introducing additional error of if this is just a rounding issue.

Good day! Thank you so much for your work, he helped me a lot with this board!
There is a problem with the firmware for 16 inputs, inputs 1-8 do not work, immediately after the firmware they are marked in red, no settings could make them work. On the same board, the firmware for 16 outputs works fine, tell me what to do?

Добрый день! Огромное спасибо за ваш труд, он очень помог мне с данной платой!
Есть проблема с прошивкой на 16 входов, не работают входа 1-8, сразу после прошивки отмечены красным, никакими настройками не получилось заставить их работать. На этой же плате прошивка на 16 выходов отлично работает, подскажите что сделать?

Hi,
I have downloaded the latest version of 16Outputs and connected the device to an Eight Relay Module.
When I turn the module it switches all the relays ON and then back OFF. Also my relays are all active low that means when I turn the relay ON it will turned OFF and vice versa.
The older version had an invert - I could not find it in the new version.
I need to get rid of the turn on of all relays at start and also to be able to invert the states of the relays.
can a flag be set in the EEPROM to say if the Relay is Active High or Low and By reading it it will set the interface and pull the relays to their previous state on Boot and Restart?

Thanks!

Issue found and resolved by Jose Vieira. I'm documenting it here in hopes that internet searches will bring other users to this solution. While this wasn't a Network Module issue it may be useful to anyone still using Windows 7.

The symptom: Running Mosquitto on Windows 7. During initialization of the Network Module some MQTT messages were being "dropped", sometimes resulting in repeatedly disconnecting the Network Module and restarting the connection. Testing showed this did not happen on Windows 10.

The solution: Jose found this solution which was directed at Windows 7 gaming users, but ended up being the solution for the dropped MQTT messages:
https://forums.malwarebytes.com/topic/26628-windows-7-reduce-network-latency-for-gaming/

Jose's paraphrased comment: "Made step 1 no result. Made step 2 worked like a charm. Narrow down to adding the TcpAckFrequency key on the registry of the LAN card that serves the connection to mosquitto broker."

Summary of the "step that worked":

• Open regedit
• Navigate to the following registry key:
  HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\Tcpip\Parameters\Interfaces
• You will need to know what IP address your computer has on your local network (not on the Internet), and then find the subkey under 'Interfaces' that has the correct IP address.
• Once you find it, you need to add two registry values to it. They are both 32-bit DWORD values. They are as follows:
  TcpAckFrequency
  TCPNoDelay
• After adding both of those, double-click on each one, and give them both a hexadecimal value of 1.
• Exit regedit

Once the above was done there were no dropped MQTT messages in Windows 7.

Hello,

firstly thanks for your great work! Your work makes the hw-584 card much more usable !

I am using a sixteen channel relay-card (should be saint smart with optocouplers).

My problem is that the gpio outputs need to be inverted have the right result that is shown on the web-interface
(mqtt commands and weblinks are wrong, too).
It would be great to have a button on the config-page to set this permanently to inverted or not inverted outputs.

I would have fixed this myself but I had trouble using the stvd to import the project to a workspace ....

Thanks a lot for your efforts!

This was originally requested in Issue #21 by mkukik.

mkukik: "... I understand why you have opted for same pattern of URL to control Relay On/Off as in original implementation, but I think if there is just rest api it could be made more transparent.
Old:
//IP:port/00 = Relay 1 OFF
//IP:port/01 = Relay 1 ON
New:
//IP:port/R01/0 = Relay 1 OFF
//IP:port/R01/1 = Relay 1 ON
or whatever suits better..."

It would be nice to allow the user to specify an internet URL (like "test.mosquitto.org") instead of an IP address in the IP field for the MQTT broker.

Try this: Delete the last digit of the MAC address, then type in the same digit that was there before. Click Save. A module reboot occurs, but no "wait 5s" message occurs. Nothing should have changed in the POST, so a reboot should not have occurred.

Next try this: Delete the last digit of the MAC address, then click Save. A "Please use requested format" popup will occur. Enter the deleted digit exactly as it was before, then click Save again. A reboot occurs, but no "wait 5s" message occurs. Nothing should have changed in the POST, so a reboot should not have occurred.