Budget: 20000 UAH Deadline: 30 days
Good day, if you have all the documentation with the set of commands, I am ready to complete your task
Breadboard
ESP32-S3-ETH
RS-485 TTL modules HW-519 — 4 pcs.
Multiplexers: HW-178 or CJMCU-4051
M-Bus master to TTL converter
DC-DC converter 24V → 5V
Power supply 24V 3A
Temperature sensor XY-MD02
2 water meters with M-Bus overlays
Sharky 775 heat meter with M-Bus module
NIK meters:
NIK 2100 AP6T.2200.MC.11
NIK 2307 0.5s ART T.1620.MC.22
Manufacturer documentation on the RS-485 protocol (for meter operation)
Controller: ESP32-S3-ETH
Available UARTs: 3 hardware UARTs
Converters:
5 x RS485-TTL (HW-519 or compatible)
1 x M-Bus-TTL Master
Multiplexer: HW-178 or CJMCU-4051
Additional modules: DC-DC, temperature/environment sensors
One UART (UART1 or another available) of ESP32 is used for reading from 6 channels via the multiplexer.
The multiplexer switches access to one of the 6 converters at any given time.
Multiplexer switching logic is implemented through 3 GPIO (S0, S1, S2).
Scanning devices on M-Bus: identifying active addresses
Polling each M-Bus device by its unique address (identifier)
Collecting and parsing consumption values or other indicators
Scanning each of the 5 RS-485 channels for devices (can be implemented via polling known addresses or NIK protocols)
Polling each device on the channel (address, model)
Supporting requests for NIK 2100 and NIK 2307 (details in notes)
All results should be structured in JSON format, for example :
{
"data": [
{
"device": "NIK 2100 AP6T.2200.MC.11",
"id": "1234567890",
"type": "rs485-1",
"value": "128.45",
"timestamp": "2025-05-05T12:34:56"
}
// ...other devices
]
}
The final format will be determined during collaboration
Output file in .ino format for Arduino framework (for PlatformIO or Arduino IDE)
Implement polling loop:
Polling interval — configurable (e.g., once every 5 minutes)
Store JSON results in RAM (output via Serial, UART, or Ethernet)
Timestamps — via RTC or NTP (if needed)
Ready and tested .ino firmware file that:
polls all 6 channels (M-Bus and RS485-1…5)
generates valid JSON with device data
outputs JSON via Serial
2. Firmware documentation
Notes:
Additional information regarding RS-485 operation for NIK meters:
NIK 2100 AP6T.2200.MC.11 and NIK 2307 0.5s ART T.1620.MC.22 use a protocol based on IEC 62056-46, -53, -61, -62 standards, which involves HDLC framing and COSEM/DLMS data structures.
Communication with the meter includes stages:
Initialization of connection (sending SNRM frame and receiving UA response).
Authorization via AARQ packet with password (user, operator, or administrator).
Processing AARE response to verify authorization.
After authorization — exchanging GET requests using OBIS codes to read indicators.
Ending session with DISC packet.
Authorization uses a 16-byte password transmitted in the AARQ field. Access type (user/operator/admin) is set in the user ID.
After 5 unsuccessful authorization attempts with the same ID, access is blocked for 30 minutes.
All packets are wrapped in HDLC structure with CRC checksums (calculated with 16-bit CRC, algorithm provided in the documentation).
Meter addressing is done in HDLC format based on serial number (conversion algorithm also provided in the documentation).
Note that not all meters may respond to address scans — in such cases, polling by a known list of serial numbers is possible.
Budget: 20000 UAH Deadline: 30 days
Good day, if you have all the documentation with the set of commands, I am ready to complete your task
это на ПК даже будет довольно сложно реализовать, а вы хотите на ЕСП32 что бы фрилансер сделал
нанимайте команду какуюто или фирму
Добрый день!
Для этого проекта ESP 32 будет явно слабовата для стандарта DLMS/COSEM запроса. Если взять RPI можно продолжить разговор...
A patch is required for the graphics card driver that expands the capabilities of managing the graphics adapter by adding additional user settings. The patch must integrate into the existing driver architecture without disrupting its core functionality and ensure compatibility with supported versions of the operating system. The main goal is to provide more flexible access to parameters that are not available in the standard driver control panel, with the ability to modify them through a user interface or software API. The patch should provide a modular structure that allows for the addition of new parameters in the future without significant code redesign. It is necessary to ensure proper error handling, change logging, the ability to revert settings to default values, as well as maintain compatibility with future driver updates as much as possible. The solution should be accompanied by technical documentation describing the architecture, implemented capabilities, limitations, and testing recommendations.
We are a large logistics company with our own exports. We have a large fleet of vehicles and we constantly send our own vehicles for export to European countries.Description Website: https://echerha.gov.ua/ On this website, we place our vehicles in an electronic queue for crossing the state border. During registration, the following data must be entered: driver's first and last name; foreign passport number; email address; logistics phone number for notifications; type of vehicle (cargo); manufacturer's name of the vehicle; state registration number of the tractor; state registration number of the trailer; customs declaration number. A specific day and time for crossing the border is predetermined for each vehicle. For example, the vehicle must pass through the "Rava-Ruska" checkpoint on Monday at 10:00.Our Problem - The queue on the website https://echerha.gov.ua/ moves unpredictably. - For example, today is Friday, and the vehicle must cross the border on Monday at 10:00. - We do not know exactly when the queue will start moving. This can happen on Friday evening, at any time on Saturday or Sunday, early in the morning, during the day, or late at night. - When the queue starts moving, it is immediately visible on the website. Sometimes, within just a few minutes, it can move from Friday to Monday or even to Tuesday. - Because of this, logistics personnel are forced to constantly monitor the mobile application or website to not miss the moment when the queue reaches the required date and time. If this moment is missed, we physically cannot place the vehicle in the queue for the needed time slot.Task - After entering the vehicle data (for example, into a table or another interface, depending on the programmer's implementation), the system should automatically track the movement of the queue. - When the queue reaches the predetermined date and time, the system should automatically fill in the necessary data and place the vehicle in the queue without the involvement of the logistics personnel.
Looking for an experienced TrinityCore 3.3.5a developer who has a good understanding of the core architecture, Battleground system, C++, SQL, and the WoW 3.3.5 client. A custom Battleground “Slavery Valley” has already been integrated into the project, transferred from AzerothCore to TrinityCore. The main part of the work has already been completed, but it needs to be brought up to Blizzard's standards.What has been done TrinityCore 3.3.5a + Eluna. The server is fully configured. The Battleground is integrated into the core. Entry into the BG works. Client UI works (partially). Most SQL and DBC have been transferred. Builds without errors.What needs to be done Fix remaining Battleground bugs. Bring the mechanics up to the level of official Blizzard Battlegrounds. Fix the match start phase. Implement correct starting gates/fire walls. Fix point capture mechanics. Fix match completion. Check score allocation and WorldState functionality. Fix remaining C++ and SQL issues. Conduct a full gameplay test.Requirements Mandatory experience: TrinityCore 3.3.5a; C++; SQL (MariaDB/MySQL); DBC; MPQ; Visual Studio; CMake; Git. Would be a big plus: AzerothCore; Eluna; experience in Battleground development; understanding of the client side of WoW 3.3.5a.Work format Work is staged. Mandatory testing after each stage. Each stage is accepted only after in-game verification. Clear reports on changes are required.In the future This is a long-term project. After completing the Battleground, the following is planned: transfer of new Battlegrounds; transfer of new arenas; new races; new classes; new game systems; further development of a custom World of Warcraft 3.3.5a server. Looking for a developer who has already worked with TrinityCore and can not only write code but also bring the system to a fully operational state.no server from 0 as I want If you are looking for a developer not just for one Battleground, but for creating a server from scratch, then the announcement should look something like this.Project Title Development of a World of Warcraft 3.3.5a server from scratch (TrinityCore / C++ / SQL / Eluna)Project Description Looking for an experienced TrinityCore 3.3.5a developer for long-term collaboration. I need a person who can develop a fully ready World of Warcraft 3.3.5a game server from scratch based on TrinityCore with further project development. The project is large and is expected to take several months of development.Project Foundation TrinityCore 3.3.5a. Maximally stable and close to Blizzard base. Eluna Lua Engine. MariaDB. Visual Studio + CMake. Git.What is planned to be implemented Fully operational server 3.3.5a. Fixing core bugs. Development of new game systems. Integration of custom Battlegrounds. Integration of new arenas. Transfer of useful modules from AzerothCore to TrinityCore. Development of custom modules. New PvP and PvE systems. New game events. Class balancing. Additional progression systems. Improvement of server performance.In the future After completing the basic part, the following is planned: new races; new classes; new zones; new dungeons; new raids; new Battlegrounds; new professions; new game mechanics; integration of modern systems into the 3.3.5a client.Developer Requirements Mandatory: Excellent knowledge of TrinityCore 3.3.5a. Confident knowledge of C++. SQL (MariaDB/MySQL). Git. Visual Studio. CMake. Understanding of TrinityCore architecture. Experience with Battleground, PvP, and game mechanics. Would be a big plus: Experience with AzerothCore. Eluna Lua Engine. Working with DBC and MPQ. Experience in creating custom game systems.Work format Work is staged. Each task is documented as a separate technical assignment. Mandatory testing after each stage. Work is accepted only after verification directly in the game. A developer is needed who can bring functionality to a fully operational state, not just write code.