Common mistakes — Frigomar gateway

General problems of this family of gateways (LED codes, box invisible on the bus, firmware update) are in Common mistakes. This chapter is what goes wrong with the Frigomar side specifically.

Nothing at all on device/21/…

The gateway publishes a unit only while that unit is answering on its serial channel. No answer, no topic — not even zeros. Work down this list in order:

Likely cause	How to tell	Fix
The air conditioner is switched off	its cabin panel is dark	power it up; the gateway needs the unit's controller running, not just the wires in place
The serial link is not reaching the unit	LED normal, MUXEN side fine	check the RS-485 pair and the ground, and the termination at the unit's end
A and B swapped	total silence rather than errors	swap the two RS-485 wires on that channel
The panel is not at 9600 baud 8N1	total silence	those values are fixed by the firmware and cannot be changed by a parameter, an overlay or a command. Set the panel to match
Wrong Modbus address	one channel silent, others fine	the gateway talks to RemoteAddr (default 1) and never searches the line — read the address on the panel and write it
Wrong firmware in the box	ProductId is not 010010019	check it, and load the right image

One unit is missing and the others stutter

A channel with nothing on it waits for the reply timeout before giving up, and the four channels are polled in turn. One dead channel therefore slows the other three down: readings arrive less often everywhere, not just on the missing unit.

If a channel is permanently unused, that is the cost of leaving it wired to nothing. Fixing the silent unit fixes the pace of the others.

The units are in the wrong cabins

Nothing in the gateway knows which cabin is which. The serial connector decides which MUXEN device a unit appears as, and the numbering in Commissioning decides which name the boat gives it. If the forward cabin answers as the aft cabin, either move the cable or renumber the two channels — do not try to fix it on the Frigomar panel.

Two gateways report the same units

The HVAC devices of this firmware ship as instances 0, 1, 2 and 3, not as "not addressed". A second gateway installed straight out of its box publishes over the first, and the boat sees four air conditioners whose readings jump between eight machines.

Number the second box before connecting it to the MUXEN bus, one channel at a time:

muxen-uds -i can0 -F 21 -I 0 writeconfig --name InstanceNum --value 4 --reboot

muxen-uds -i can0 scan lists what is on the bus; function 21 must appear once per real air-conditioning unit.

--preferred-function-code 21 times out

Expected. The air-conditioning devices cannot be numbered by UID — that route exists only for the box's own generic I/O (function 17). Address the HVAC devices directly with -F 21 -I <current instance>.

A command does nothing

Likely cause	How to tell	Fix
The gateway is not hearing the unit	no life topic in the last few seconds	see the first table — nothing is written to a unit that is not answering
The set point is out of range	{"command":1,...} with a value below 18 or above 30	only 18…30 °C is accepted, and anything else is discarded without a word
Wrong instance	another cabin changed instead	check the instance in the topic
The unit refuses	the command reaches it, nothing changes	its controller has the last word — a compressor in its restart delay will not start

Only two things are commanded: running mode ({"command":0}) and temperature set point ({"command":1}).

Mode and fan speed cannot be changed from the boat

Correct, and deliberate. The gateway reads the operating mode (heating, cooling, dehumidify, auto, fan) and the fan speed and puts them on the screens, but it never writes them. Change them on the cabin panel. Keep those controls off any screen page that drives a Frigomar.

The air conditioning switches itself off

That is the battery protection, and it is doing its job. In automatic mode the gateway switches a unit off whenever the park it is bound to reports overload, low battery, no battery at all, or a state of charge below MinSocToWork.

Two ways to be surprised by it:

Symptom	Cause	Fix
a unit is held off permanently and nothing on the boat looks wrong	BindToParc points at a park where no battery publishes — the gateway reads that as "battery off"	write the park number the batteries actually use, or 255 for standalone
the protection never triggers at all	BindToParc is 255 (standalone), which the gateway writes at the very first start because an air conditioner cannot detect its park on its own	bind it to a real park

It does not come back on when the battery recovers

By design. The gateway switches a unit off to protect the batteries; it never switches one back on. Start it again from a screen or from its wall switch once the park has recovered.

The battery protection is ignored

Any explicit on or off command from the boat puts that unit in forced mode and switches the protection off for good. Give it back with:

mosquitto_pub -h 127.0.0.1 -t 'device/21/<instance>/command' -m '{"command":0,"parameter":2}'

A restart of the gateway also returns it to automatic.

The wall switch does nothing

Likely cause	Fix
the unit is in forced mode	send the auto command above
the battery park is not in a healthy state	the toggle is ignored while the park is in overload, low battery or below MinSocToWork
the equation names a device that does not publish	check the instance — inside an equation, instance numbers are written one higher than the device's instance number
a syntax error in RemoteCmdEqn	a malformed expression is simply never true; read it back and compare with Reference — Frigomar gateway

An alarm stays raised after the unit is switched off

The alarms of a unit are refreshed only when that unit answers. Switch an air conditioner off at its breaker while it has a fault and the alarm stays on the boat's screens, republished every second, until the unit comes back and reports itself clear.

The same applies while a fault changes: the gateway clears the whole fault list only when the unit reports no fault, so a machine that walks from one fault to another can show both at once until it settles. The cabin panel is the authority when the two disagree.

The air conditioner shows battery park 15

Cosmetic. A unit left standalone (BindToParc = 255) is published on the bus with the park field saturated, which reads as park 15 on the screens. Bind it to a real park and the number becomes the right one.

The box's own relay and analog input never appear

Symptom	Cause	Fix
nothing on device/17/…	the I/O device ships not addressed (InstanceNum = 255)	give it an instance number, and set EnGenIo to 1
only one relay and one analog input	that is what this box has	the second relay, the two dry-contact inputs and the second analog input of the generic I/O device are published as 0 and are not wired to anything

I changed a setting and nothing happened

Settings are read once, at startup. Always write with --reboot:

muxen-uds -i can0 -F 21 -I <instance> writeconfig --name MinSocToWork --value 30 --reboot

Remember that one reboot restarts all four channels at once.

After a factory reset

The four HVAC devices go back to instances 0, 1, 2 and 3, the generic I/O to 255, and every channel loses its park binding, its Modbus address and its wall-switch equation. Re-number the four channels before the box goes back on a bus that already has air conditioners 0 to 3.

There is no undo — read the configuration out and keep it first.