EM-482 interface converter by Novatek-Electro

Another device from Novatek, and this time we're looking at an interface converter—in this case, from RS-485 to WiFi, with data transmission over the MODBUS-TCP protocol.
As always, we'll take a look, take it apart, test it, and draw some conclusions.


As usual, the link in the title goes to the Ukrainian website. For readers in Russia, here's a link to the Russian website, although for some reason this model isn't available for sale there yet.

I'll start with what this module is for.
Simply put, it lets you connect devices that use RS-485 to a local network over WiFi.
To put it in a little more detail, it doesn't just connect devices; it also lets you work with them through the Overvis cloud service. You can retrieve data from devices connected to the EM-482, control them, set up notifications, and do plenty more over the MODBUS network. This module has an Overvis page with information about how the device works and what it can do, so there's no point in copying it all here.


The packaging is no different from that of Novatek's other similar devices, apart from the sticker.


Inside are the manual and the module itself. The contents are very basic.


I wouldn't call the manual particularly comprehensive, but it does include everything you need. In my opinion, the most important parts are how to set up the WiFi connection and the warranty information. As with many of its other devices, the manufacturer offers a 10-year warranty.


As always, the manual is available in digital form, and I'll quote a few excerpts from it.
For the technical specifications, the main things to know are the supply voltage, current consumption, WiFi operating frequency, and supported protocols.


The package also included stickers with QR codes for connecting to Overvis. The code is unique, of course, so I had to blur it in the photo.


It's the same size as a standard circuit breaker, one module wide.


1. Two terminals at the top for the power supply and three for the RS-485 interface.
2. Two pass-through power terminals at the bottom, though as far as I know, current versions of the module no longer have them.
3, 4. The wiring diagram is on the side; the clips underneath are for mounting it on a DIN rail, just like on other modules.

There's also a sticker with the serial number on the side. If you've lost the warranty card, I think you can still make a warranty claim using this sticker, but in that case the warranty period will start from the date of manufacture.


The front panel has four LEDs and a button.
1. Hold the button for 2 to 8 seconds to put the module into WiFi setup mode. Hold it for more than 8 seconds to reset the settings to factory defaults.
2. Power LED: green during normal operation and red when entering setup mode.
3. SRV indicates data exchange with the server; it stays on continuously during operation.
4. 485 indicates data exchange over the RS-485 bus; it flashes frequently during data transmission.
5. WiFi indicates a WiFi connection (steady light) or connection attempts (flashing).


Unfortunately, I couldn't find a decent photo, but this module comes in two versions: with an internal antenna (EM-482) or an external one (EM-482-1). The latter has a connector underneath for the antenna.


There are three devices in the series, each with a different network connection option:
1. EM-481, connects via Ethernet or GSM and supports a memory card; the most feature-rich model.
2. EM-482, the module reviewed here, connects via WiFi.
3. EM-483, Ethernet connection.

In essence, models 482 and 483 are the most similar, but since model 481 can also connect additional devices via RS482 and send data to cloud storage, I included it in the overall list as well.


As usual, a little about the module itself.
It comes apart like the other modules, though this one hadn't been glued together yet, so it was relatively easy to open.


The main board, viewed from above. The ESP module and its ceramic antenna are clearly visible, as is the connector for an external antenna. I'll have to try connecting one.


There are far fewer components on the back: the controller and flash memory.


Besides the main board, there are three additional ones:
1. Bottom board: power supply
2. Middle board: RS485 interface
3. Top board: indicators.


1. Everything is controlled by an STM32F091-series microcontroller
2. Flash memory nearby: 25SF321
3. SN65HVD11 RS485 transceiver
4. TPS5430 switching regulator. A polymer capacitor is installed after it, which should improve reliability.
5. It's curious that there's a spot on the board for supercapacitors. At least, I can't think of what else it could be for.
6. There's a reverse-polarity protection diode near the power connector. The mirrored lettering also lifted my spirits a bit.


I used a Meanwell HDR-15-24 24 V power supply.


To enter setup mode, hold the button for 2–8 seconds. You can release it as soon as the top LED turns red; all three LEDs at the bottom will be lit at the same time.
A few seconds after releasing the button, the second and fourth LEDs should start alternating, while the Power indicator stays green.


1. Go to the Wi-Fi settings on your phone or laptop, for example, and find EM482 in the list of networks
2. Connect to it; no password is required.
3. Open a browser and enter em.com or 192.168.4.1 in the address bar to get to the settings page. If you're using a phone, quietly swear under your breath, because not everyone has a microscope at home.
4. Somehow zoom in, tap the top field to open the list of available networks, and select yours (or someone else's, whatever works for you)
5. Enter the network password in the field just below.
6. Reboot the device using the Reset button at the very bottom of the page. That's it.

You can configure the operating modes here too, but everything worked fine for me with the defaults.


Next, I followed the QR code to ocp.overvis.com. The device's unique code was filled in automatically, but there were a few snags.
First, I'd forgotten the password for my previous account, so I had to register again. But imagine my surprise when, after a few attempts to remember the password, I realized I'd entered the same one for the new account. Along the way, I found that:
1. When you try to reset your password, the email never arrives. That's a bug, though
2. Your email address is used as the login, which is common enough, but making the email field case-sensitive... that's an even bigger bug. That's why my password wasn't accepted.
3. If you enter the wrong password too many times, you'll eventually get an HTTP ERROR 444, tied to your external IP address. It clears after a while; you could consider it brute-force protection.

The password case issue is very simple: it's easier to connect to the device initially using a smartphone, and when you start entering your email in that field, the first character is capitalized by default. When you log in from a PC, though, you usually use lowercase, so the login/password combination won't work. I reported this bug a year ago, but it still hasn't been fixed.

Next, a device network is created, and you'll be prompted to add devices to it. You can also assign them addresses on the RS485 network there.


This was genuinely nice: Novatek doesn't just let you add devices, it also links them to a MODBUS command set. And judging by the selection list, it includes devices from other manufacturers, not just their own. The list is extensive; what follows is only a small sample.


Somehow I ended up finishing the setup in Overvis on my PC, and that's where I ran into an “issue”: I didn't know which IP address to use because I didn't know what it was. When connecting in WiFi setup mode, go to 192.168.4.1 or em.com. After rebooting, the device gets an address from the router via DHCP.


If you enter an IP address that isn't used by the device, it will be added, but of course it won't work.


In the end, I had to check the router to see which address the device had received. Personally, I'm not a big fan of DHCP and usually try to use a static address.

Once connected correctly, all the module settings are available through overvis. They look a little different here than in the WEB interface, of course, but there are not only more of them; you also get access to additional data, such as traffic, interface load, and even the device's supply voltage.
It's a little strange that there's no separate software for easier configuration. On the other hand, you usually only do this once, and compared with the settings on some PBXs, everything here is completely straightforward :)


At the top of the settings page, you'll find information on the time since the last reboot, total uptime, traffic, channel load, and more.


To start with, I decided to experiment with the OV-215 module, which I connected to the unit under review via the 485 interface.
In the settings, you need to select Modbus TCP as the communication mode and enter the IP address of the interface converter.


Well, it works. I started by clicking the relay on and off. There's a slight delay, which makes sense; poor connection conditions may also have played a part, and the WiFi connection was through a repeater.


For the second stage, I simulated pulse counting with the OV-215, checking the results not only in its software but directly in overvis as well. To view the incoming data "live," you need to enable faster updates by clicking the corresponding option. Click it again to turn off auto-refresh.
I tried shorting the counter input, and the readings changed accordingly.


When I launched the software, I got the same values.


For the next test, which is closer to a real-world application, I'm putting together a small setup consisting of:
1. PEF-321AVR automatic transfer switch controller
2. OV-215 input/output device
3. EM-482 interface converter
4. Meanwell HDR-15-24 power supply

As you can see, the only non-matching component here is the power supply, but it's from a trusted manufacturer, so there shouldn't be any compatibility issues.


The OV-215 was already configured and assigned address 2 on the RS485 network. For the AVR, I set the following parameters:
rPP- 2 (communication via RS485)
bUS - 1 (RTU protocol)
nPP - 1 (address on the RS485 network)

I was wary of connecting it to a computer, so I made all the settings through the AVR's own panel.


I added the corresponding devices in overvis. OV-216 instead of OV-215 is a typo.


I could have connected more devices, but the free version is limited to three active devices. I didn't want to activate the free month, since reviews sometimes take a while and the trial can expire before I'm done. I'm not quite ready to pay 89 euros a month for the full version, either.
And really, two devices—or even one—were more than enough for the test. You'll see why later.

The full version of overvis lets you create visualizations, send SMS notifications, I think, and do plenty more. Though these days, it would probably be easier to send something other than SMS and make a proper app with all the necessary bells and whistles. But that's beside the point. If you're interested, you can visit their website, connect to overvis, message me on Viber, or just ask me.


I entered the same parameters in the AVR software settings.


And this is where the "trouble" started, though it was pretty much predictable. The connection kept dropping. The two programs worked together only when there was no communication with the OV-215 software. To be fair, reception conditions were far from ideal.


My first thought was that the power supply might be partially shielding the WiFi signal, so I moved the EM-482 all the way to the right. Only later did I realize this probably didn't make much difference, since its WiFi antenna is on the left and was still shielded by the neighboring module.


If that did help, it wasn't by much.


The ATS software can log the data it receives to a PC, which made it easy to monitor whether it was working properly. You can clearly see that the connection kept dropping, but then recovered each time.


After that, I moved my setup closer to the WiFi repeater. The connection was clearly more stable, but a different problem appeared: it wouldn't reconnect on its own.


I moved it to another room and reconfigured the connection to use the main router instead of the repeater. The results were still not very stable.
Then I swapped the modules around so that nothing was blocking the WiFi antenna on the EM-482.


More out of curiosity than for any practical reason, I tested receiving data on two computers at the same time.
It works, more or less: you can run two copies of the same software and see the data on both PCs in sync. As far as I understand, up to four connections are supported, either with four different programs or with multiple copies of the same one.


The connection was a little less stable this way than before, but that makes sense. Looking at the monitoring data, I found that RS485 utilization was around 95% in this setup, compared with about 55% with a single connection. In other words, the interface was overloaded in the first case.
It also turns out that the problem was not between the converter and the software, but between the target device and the converter, since two copies of the software were querying the ATS at the same time. That's odd; I thought that with one target device and two copies of the software, the load would still be 55%.


You might ask, why not increase the communication speed? I tried setting it to 19200 instead of the default 9600.
But either I was doing something wrong, or the software just wasn't having it. Nothing changed.
1. The converter supports speeds from 75 to 921 600, but the ATS only goes up to 19200.
2. The load did drop a little, but not by much. The third device out of the four available was an attempt to connect to the OV-215.


While experimenting, I noticed a link to a newer software version on the manufacturer's website, so I checked what was installed by default and was a little surprised.
The manual lists software versions, changes, and release dates. It turned out I had version 5, while version 7 was available for download. It had been released a year and a half earlier, and I have no idea how I ended up with a device running such old firmware.


I managed to update it, more or less. The problem was that I was doing it on my phone, since my PC doesn't have WiFi, and on one of my phones, whenever I tried to open the firmware file, it stubbornly kept offering to open the gallery.
The update process itself is very simple. I have to give the developers a big thumbs-up here, because the device can hold two firmware versions at once. The base firmware is always there, while the updated version is loaded as a user version, so you can always roll back to the original.


At first, it seemed just as bad, but after restarting, it turned out to be more stable after all. At least, data was being transmitted from about 2:30 a.m. until 8:30 a.m. The brief data loss on the graph was an automatic software reconnect; where the gap is larger, I reconnected manually.
The graph covers about 20 hours from the software update and reboot.


If you think I stopped there, you don't know me very well :) As a last resort, I grabbed an antenna with a cable, opened the EM-482 case, and connected it to the WiFi module's built-in connector. And yes, as far as I can tell, the connector is connected to the module; at least, I could see a capacitor or jumper on the connector's center contact.


In the end, nothing changed. The software could keep the connection going for a long time, or drop it after just ten minutes. So I can only conclude that the problem isn't signal quality, but rather some kind of software quirk.


But another oddity showed up. Normally, if you open the EM-482 settings, you see both its configuration and its statistics. After I installed the antenna and rebooted the device, some of the information disappeared.
The device stopped displaying its RS485 network address (it was 111), data transmission speed, and operating mode. If you scroll further down, it couldn't read data from the device or, naturally, write new data to it.
But interestingly, it worked exactly as it had before.


I tried reinstalling the devices in overvis, deleting the network and setting it up again, and assigning different RS485 addresses. The result was absolutely zero.
I managed to change something completely by accident when I opened the Overvis connect reinstallation menu. There is a Modbus settings item where you can change the data transmission speed and format. You can change something, or leave everything as it is and simply click “Write”—and, as if by magic, everything starts working correctly.

Unfortunately, though, it doesn't last long—apparently only until the next time it reconnects to overvis. I don't think this could have happened because I installed the antenna; I suspect it was just a coincidence.

I also found another oddity: if the EM-482 is set to 9600 and the AVR to 19200, everything works. But if both devices are set to 19200, there is no connection to the device. I hadn't noticed this when I checked earlier.


After a lot of experimenting, I found that the device effectively has four states:
1. Full operation: data is sent both to overvis and to the PC software.
2. Simplified operation: data is sent only to overvis. This can happen either when the software isn't running or when it has “dropped out.”
3. No data is being sent anywhere, either because the RS485 interface is overloaded or for some other reason; it's hard to say. In this state, only the SRV and WiFi indicators are lit.
4. The device is connected to WiFi but, for some reason, has disconnected from overvis. Only the WiFi indicator is lit.

The last two situations are shown in the photo.


This is what normal operation looks like: the RS485 communication LEDs on the AVR and EM-482 flash frequently, while the SRV and WiFi indicators stay on continuously.
Sorry about the image quality. I had to shoot without bright lighting so the indicators would be easier to see.


Here I accidentally caught a connection problem with overvis. You can see that WiFi keeps working, but the other indicators behave strangely. At this point, the software was no longer connected to the device—that's why I wanted to record it.
After a while, attempts to communicate with the AVR stop altogether, i.e. the RS485 indicators go inactive.


I noticed that data is transmitted much more reliably to overvis, although there are still some dropouts.


I still have some doubts about the previous screenshot—perhaps my actions caused the dropouts. But in this screenshot, as in the other one, the dropouts happened overnight or in the morning, when I definitely wasn't doing anything.


Of course, monitoring and data logging are genuinely useful. As far as I can tell, it records a lot of parameters at once, and you can choose which ones you need when viewing the data.


There are notification settings, although as I understand it, SMS messages cost extra. That's why I think separate software with notifications over the internet is a better option.


You can also create visualizations to make the incoming data easier to read. I haven't looked into it; if you're interested, you can read more here, but as I understand it, everything is configured as code.


Those are overvis's capabilities. As for the device itself, by the time I wrote this review it had been running for almost five days. After the last reconnection through the software, it worked normally for a few hours, but then the connection dropped again.
For example, here it's clear that I'm not receiving information about the address and RS485 settings, even though data is being transmitted.


Conclusions.
Honestly, I wanted to praise it. I liked the capabilities—or, more precisely, the functionality of the device, which lets you not only transmit data but also configure the device flexibly and monitor its operation. I'd also like to point out overvis's features: you can use Modbus to work not only with Novatek devices, but with devices from other manufacturers as well. I noticed this difference especially when comparing it with one of the MOXA NPort 5200 converters I used.

Unfortunately, all the advantages I was so pleased with were wiped out by stability problems with this system. Maybe I was just “lucky”; maybe this is a general issue with this device. I can't say, since I tested only one unit, so I'll base my comments on my experiments.
I tested:
1. operation under different conditions through a WiFi repeater
2. operation connected to the main router.
3. with the old and new firmware
4. with the internal and external antenna.
5. with different settings
6. connected only to the ATS (without the OV-215), though with old firmware.

But in the end, it turned out that when connected using the native PC software, the connection tends to drop out. Sometimes it comes back, sometimes it doesn't.
The records in the Overvis cloud service look more stable, but not as stable as I would like; some of the data is missing there too.

Of course, you could say that Wi-Fi and industrial devices are mutually exclusive, and I've never argued with that. I won't argue now, either. But friends, most of the tests were carried out under near-ideal conditions: no interference, and although the router wasn't in direct line of sight, it was definitely within reliable range. And since the problem persisted even after I added an external antenna, the issue may not be the connection quality.

I'd also like to point out a few software-related oddities, for example:
1. I set the ATS to address 3 on the network and enter the same address for the converter, but when I connect through the software, it only works if the address is set to 1, not 3.
2. As I wrote above, the ATS is set to 19200 baud and the converter to 9600, and everything works. But if I set it to 19200, there's no connection to the ATS. This issue appeared later, too.
3. After a software update (presumably), I could no longer read or write the EM-482 settings, although data is still being transmitted and the EM-482 itself is still being monitored. Saving the settings again from Overvis Connect restores normal operation, but only for a while.

So, that's the strange device I ended up with. I'll of course send the review link to the developers. Maybe they can explain the problem in more detail—or, even better, help fix it. I admit it's possible I did something wrong myself, but as you can see from the screenshots, the main settings are more than straightforward. And after all the experiments I ran during testing, I would have stumbled on the right configuration at least once, even by brute force.

That's all from me. I hope this information was useful, and I'd be glad to hear your comments—and especially your questions.