Just looked at the PDF doc, isn’t very clear but that’s usual 
You play at suck it and see.
My first guess would be to write 169 as a 16 bit int
That does not appear to be a readable register; you’d read mode from register 473
EDIT - I now think the PDF means r/w when it says write
I’m not sure if those are register numbers or addresses, you may need to do the -1 thing.
I tried all the following combinations so far (all without success)
start: 168 & 169
type: int16, int32
length: 1 & 4
Everytime int16 is used I get errors in the log.
Other types results in no errors but mode is not switching.
Will do a little more trying around tomorrow.
Yeh, elsewhere the PDF is fairly consistent in wanting 32-bit write.
This post above looks like your reference
I cannot recall if the binding is smart enough to assert writeMultipleEvenWithSingleRegisterOrCoil when selected type is 32 bit - but I suspect this is the magic you are missing.
with
Thing data register [ readStart="168", readValueType="uint16", writeValueType="int32_swap", writeStart="168", writeMultipleEvenWithSingleRegisterOrCoil=true, writeType="holding" ]
it seems to “work” but my problem now is that I can switch back to Manual mode (no bypass) but I cannot switch to any other mode (bypass on / summer)…
What values are you sending? What values do you read back? events.log is probably good to show this. Make autoupdate=“false” on your Item to prevent that interfering.
Are you reading 473 (address 472) for actual mode?
I’m starting to figure out some things (finally)
here is my simplified setup:
Item
Number Pluggit_ActiveUnitMode "Active Mode [MAP(Pluggit.map):ActiveUnitMode_%s]" <settings> (gPluggit) { channel="modbus:data:PluggitAP310:prmRamIdxUnitMode:register:number" }
Thing
Bridge modbus:tcp:PluggitAP310 [ host="192.168.143.4", port=502, id=1 ] {
Bridge poller prmRamIdxUnitMode [ start=168, length=4, refresh=5000, type="holding" ]
{
Thing data register [ readStart="168", readValueType="uint16", writeValueType="int32_swap", writeStart="168", writeMultipleEvenWithSingleRegisterOrCoil=true, writeType="holding" ]
}
}
Sitemap
sitemap home label="home" {
Frame label="General"
{
Selection item=Pluggit_ActiveUnitMode mappings=[
4 = "Bypass-Auto (4)",
132 = "Bypass-Manuall (132)",
2048 = "Summer (2048)",
128 = "Bypass On(128)",
32896 = "Bypass On (32896)",
2052 = "Summer-from-Pluggit (2052)",
2180 = "Bypass-Manuall2 (2180)",
34816 = "Stop Summer (34816"
]
}
}
I gathered some Info about the modes by switching the HVAC via the pluggit app and my “smart home” system (myGekko).
This is what I found out:
The App and my Smart-Home Screen give me 3 Options (and I dont use the other modes like week schedule, fireplace etc.):
I’m going to use those names from now on to explain the situation
Here is the log when switching it into those modes (either from app or smar home)
Auto (bypass closed):
Pluggit_ActiveUnitMode changed to 4
Pluggit_CurrentUnitState changed to 1
Manual (bypass open):
Pluggit_ActiveUnitMode changed to 1
Pluggit_CurrentUnitState changed to 132
Summer:
Pluggit_ActiveUnitMode changed to 2052
Pluggit_CurrentUnitState changed to 6
I have now tested many modes and switching in between and cannot find a consistent method of switching between those.
Here is my list of modes and what value I sent and what the result then was… (always refering to the modes above which are (in my opinion) the correct ones.
Mode: Manual (reads 132)
Task 1 (Change to Summer)
(working) 2180 -> turns into Summer (reads 2052)
(not working) 2048 -> stays in Manual (reads 2180) aka Manual #2
(not working) 2052 -> stays in Manual (reads 2180) aka Manual #2
(not working) 34816 -> stays in Manual (reads 2180) aka Manual #2
Task 2 (Change to Auto)
(working) 32896 -> turns into Auto (reads 4)
(working) 128 -> turns into Auto (reads 4)
(?working?) 4 -> stays in Manual (reads 132)
Mode: Auto (reads 4)
Task 1 (Change to Summer)
(working) 2048 -> turns into Summer (reads 2052)
(working) 2052 -> turns into Summer (reads 2052)
(working) 34816 -> turns into Summer (reads 2052)
Task 2 (Change to Manual)
(working) 128 -> turns into Manual (reads 132)
(working) 132 -> turns into Manual (reads 132)
(working) 32896 -> turns into Manual (reads 132)
(?working?) 2180 -> turns into Manual (reads 2180) aka Manual #2
Mode: Summer (reads 2052)
Task 1 (Change to Manual)
(working) 2180 -> turns into Manual (reads 132)
(?working?) 132 -> turns into Manual (reads 2180) aka Manual #2
(?working?) 128 -> turns into Manual (reads 2180) aka Manual #2
(?working?) 32896 -> turns into Manual (reads 2180) aka Manual #2
Task 2 (Change to Auto)
(working) 2048 -> turns into Auto (reads 4)
(working) 34816 -> turns into Auto (reads 4)
(not working) 4 -> stays in Summer (reads 4)
weird mixed mode, reading a correct value of 4 which is Auto but the Unit still is in Summer mode...
Mode: Manual #2 (reads 2180)
on Smart Home Unit
-> If I want to put it in Summer it won't let me (switches instatly back to Manual reading 2180)
Selecting Auto results in it going to Auto for a second but then it goes into Summer Mode (reads 2052) so really strange
Task 1 (Change to "normal" Manual)
(working) 34816 -> turns into Manual (reads 132)
(working) 4 -> stays in Manual (reads 132)
(working) 2048 -> stays in Manual (reads 132)
(working) 2052 -> stays in Manual (reads 132)
Task 2 (Change to Summer)
(working) 128 -> turns into Summer (reads 2052)
(working) 132 -> turns into Summer (reads 2052)
(working) 32896 -> turns into Summer (reads 2052)
Task 3 (Change to Auto)
no values left to test....
So as I see the status of my ‘investigation’ now there is no consistent value that will
Am I completely off by saying that there needs to be some conditional coding somewhere that takes the current state into account and switching modes based on that (some .rules file I imagine)???
This would be kinda weird since the official pluggit app and my smart home system can do it with one button or they both also use some conditional switching behind the scenes who knows
It would be smart to read poll your Thing data register in the same format that you write it in, just in case of hidden quirks, i.e int32_swap
I don’t follow everything that you’ve done. I’d guess for many things you have to follow the sequence e.g. once in summer-on, you’d have to issue summer-stop before doing other things.
What exactly is Pluggit_CurrentUnitState ? Guessing 472 int32_swap
I’m not entirely sure if I understood your problem, but what I can definitely say:
When writing towards the device you can just chose (only) three different modes:
(from the doc):
4.5.3
Change between basic modes
Change to Demand Mode: Write 0x0002 (2) to 40169 prmRamIdxUnitMode.
Change to Manual Mode: Write 0x0004 (4) to 40169 prmRamIdxUnitMode.
Change to Week Program Mode: Write 0x0008 (8) to 40169 prmRamIdxUnitMode.
The other modes are on top of the basic modes and need to be switched on and off actively:
(section 4.5.4 Start/end other modes):
Start Away Mode: Write 0x0010 (16) to 40169 prmRamIdxUnitMode.
End Away Mode: Write 0x8010 (32784) to 40169 prmRamIdxUnitMode.
Start Fireplace Mode: Write 0x0040 (64) to 40169 prmRamIdxUnitMode.
End Fireplace Mode: Write 0x8040 (32832) to 40169 prmRamIdxUnitMode.
Start Summer Mode: Write 0x0800 (2048) to 40169 prmRamIdxUnitMode.
End Summer Mode: Write 0x8800 (34816) to 40169 prmRamIdxUnitMode.
This means e.g. that the sequence
manual mode - start summer - week mode
does not switch from summer to week mode. Most likely (haven’t tested it though) if you execute this sequence and afterwards do “end summer” the device might be in week mode (because the basic mode switched while summer was active).
If it can be established that this is how this register works, there are ways to handle individual bits in a modbus register that may be useful
I thought about the situation and figured I would use a .rule to do the switching of modes as I could not come up with a simpler way to di it (do you?).
Here is what I got so far:
import java.util.concurrent.locks.ReentrantLock
val ReentrantLock lock = new ReentrantLock()
rule "pluggit modes"
when
Item Pluggit_ActiveUnitMode received command
then
lock.lock()
try {
// read current state of Pluggit_ActiveUnitMode
val current_state = ??????
switch receivedCommand {
case 132 :
// CHANGE TO MANUAL MODE
switch current_state {
case 4 :
// Unit is in Auto Mode
// Change to Manual
Pluggit_ActiveUnitMode.sendCommand(128)
case 2052 :
// Unit is in Summer Mode
// Change to Manual
Pluggit_ActiveUnitMode.sendCommand(2180)
default :
}
case 4 :
// CHANGE TO AUTO MODE
switch current_state {
case 132 :
// Unit is in Manual Mode
// Change to Auto
Pluggit_ActiveUnitMode.sendCommand(128)
case 2052 :
// Unit is in Summer Mode
// Change to Auto
Pluggit_ActiveUnitMode.sendCommand(34816)
default :
}
case 2048 :
// CHANGE TO SUMMER Mode
switch current_state {
case 132 :
// Unit is in Manual Mode
// Change to Summer
Pluggit_ActiveUnitMode.sendCommand(2180)
case 4 :
// Unit is in Auto Mode
// Change to Summer
Pluggit_ActiveUnitMode.sendCommand(2048)
default :
}
default :
}
} finally{
lock.unlock()
}
end
The only part that is missing is reading the current state as a decimal number.
That way I set could use the switch statements to send the correct values to get me to the desired mode based on the mode the unit is currently in.
Do you know how to read the current state?
regards
Alkahna
I keep enquiring about what you find at address 472 (register 40473)
Hi all,
I continued using the modbus1 Binding, and monitor relevant data. Very nice, and thank you all for the great support here!
Now I wanted to control the AP310 using Openhab, and discovered a strange phenomena: when changing values and modes at the AP310 directly, these changes are updated in the iflow Android app on my mobile phone, as well as in Openhab. But if I change these values (e.g. switch to manual mode) in Openhab, this chnage is displayed in the mobile phone app, but the AP310 does not change state.
Did anyone also noticed this behaviour?
Best regards
Robert
Anyone got the Pluggit working with openhab 3?
I lost my openhab 2 installation and try to set myself up with openhab 3 but I’m somewhat lost on how to get it working again
I managed to get it working on OH 2.5.12 using the current binding. Configuration should work for OH3, too.
my modbus.things:
Bridge modbus:tcp:PluggitAP310 "AP310" [ host="192.168.178.210", port=502, id=1 ] {
Bridge poller AP310_1 "AP310_1" [ start=100, length=100, refresh=5000, type="holding" ]
{
Thing data pluggit_prmHALTaho1 "AP310_1 prmHALTaho1" [ readStart="101", readValueType="float32" ]
Thing data pluggit_prmHALTaho2 "AP310_1 prmHALTaho2" [ readStart="103", readValueType="float32" ]
Thing data pluggit_prmRamIdxT1 "AP310_1 prmRamIdxT1" [ readStart="133", readValueType="float32" ]
Thing data pluggit_prmRamIdxT2 "AP310_1 prmRamIdxT2" [ readStart="135", readValueType="float32" ]
Thing data pluggit_prmRamIdxT3 "AP310_1 prmRamIdxT3" [ readStart="137", readValueType="float32" ]
Thing data pluggit_prmRamIdxT4 "AP310_1 prmRamIdxT4" [ readStart="139", readValueType="float32" ]
Thing data pluggit_prmRamIdxUnitMode "AP310_1 prmRamIdxUnitMode" [ readStart="168", readValueType="uint16", writeValueType="int32_swap", writeStart="168", writeMultipleEvenWithSingleRegisterOrCoil=true, writeType="holding" ]
Thing data pluggit_prmRamIdxBypassActualState "AP310_1 prmRamIdxBypassActualState" [ readStart="198", readValueType="uint16" ]
}
Bridge poller AP310_3 "AP310_3" [ start=300, length=100, refresh=5000, type="holding" ]
{
Thing data pluggit_prmRomIdxSpeedLevel "AP310_3 pluggit_prmRomIdxSpeedLevel" [ readStart="324", readValueType="uint16", writeValueType="int32_swap", writeStart="324", writeMultipleEvenWithSingleRegisterOrCoil=true, writeType="holding" ]
}
Bridge poller AP310_4 "AP310_4" [ start=400, length=100, refresh=5000, type="holding" ]
{
Thing data pluggit_prmBypassTmin "AP310_4 prmBypassTmin" [ readStart="445", readValueType="float32" ]
Thing data pluggit_prmBypassTmax "AP310_4 prmBypassTmax" [ readStart="447", readValueType="float32" ]
Thing data pluggit_prmNumOfWeekProgram "AP310_4 prmNumOfWeekProgram" [ readStart="466", readValueType="uint16", writeValueType="int32_swap", writeStart="466", writeMultipleEvenWithSingleRegisterOrCoil=true, writeType="holding" ]
Thing data pluggit_prmCurrentBLState "AP310_4 prmCurrentBLState" [ readStart="472", readValueType="uint16" ]
}
Bridge poller AP310_5 "AP310_5" [ start=500, length=100, refresh=5000, type="holding" ]
{
Thing data pluggit_prmFilterRemainingTime "AP310_5 pluggit_prmFilterRemainingTime" [ readStart="554", readValueType="uint16" ]
}
}
This seems to work.
Thanks, I will git it a try thanks.
Is the modbus.things file the only one I need?
I cannot find the modbus.config file in Openhab 3, maps are gone too somehow.
There isn’t one. Bindings are configured with Things and channels.
What maps?
I prefer the text-based configuration.
My items-definition:
// MODBUS 2.5
Number Pluggit_SpeedFan01 "Speed Fan 1 [%.0f rpm]" (gPluggit, gPluggit_Speedfan) { channel="modbus:data:PluggitAP310:AP310_1:pluggit_prmHALTaho1:number"}
Number Pluggit_SpeedFan02 "Speed Fan 2 [%.0f rpm]" (gPluggit, gPluggit_Speedfan) { channel="modbus:data:PluggitAP310:AP310_1:pluggit_prmHALTaho2:number"}
Number Pluggit_OutdoorTemperature01 "Außen Zuluft T1 [%.1f °C]" <temperature> (gPluggit, gPluggit_Temp) { channel="modbus:data:PluggitAP310:AP310_1:pluggit_prmRamIdxT1:number"}
Number Pluggit_SupplyTemperature02 "Innenraum Zuluft T2 [%.1f °C]" <temperature> (gPluggit, gPluggit_Temp) { channel="modbus:data:PluggitAP310:AP310_1:pluggit_prmRamIdxT2:number"}
Number Pluggit_ExtractTemperature03 "Innenraum Abluft T3 [%.1f °C]" <temperature> (gPluggit, gPluggit_Temp) { channel="modbus:data:PluggitAP310:AP310_1:pluggit_prmRamIdxT3:number"}
Number Pluggit_ExhaustTemperature04 "Außen Abluft T4 [%.1f °C]" <temperature> (gPluggit, gPluggit_Temp) { channel="modbus:data:PluggitAP310:AP310_1:pluggit_prmRamIdxT4:number"}
//Number Pluggit_M2_PowerOfPreheater "Power Of Preheater M2 [%d %%]" <energy> (gPluggit)
Number Pluggit_SpeedLevelOfFans "Schreiben Speed level of Fans [%d]" <settings> (gPluggit) { channel="modbus:data:PluggitAP310:AP310_3:pluggit_prmRomIdxSpeedLevel:number" }
Number Pluggit_ActiveUnitMode "Schreiben Active Unit Mode [MAP(pluggit.map):ActiveUnitMode_%s]" <settings> (gPluggit) { channel="modbus:data:PluggitAP310:AP310_1:pluggit_prmRamIdxUnitMode:number" }
Number Pluggit_CurentUnitMode "Lesen Current Unit Mode [MAP(pluggit.map):CurrentUnitMode_%s]" (gPluggit) { channel="modbus:data:PluggitAP310:AP310_4:pluggit_prmCurrentBLState:number"}
//Number Pluggit_CurrentUnixTime "Current Unix time [%d]" <time> (gPluggit)
//Number Pluggit_StartExploitationUnixTime "Date Stamp of the system start [%d]" <time> (gPluggit)
//Number Pluggit_WorkTimeOfSystem "Work time of system [%d h]" <time> (gPluggit)
Number Pluggit_RemainingFilerLivetime "Remaining time of the Filter Lifetime [%d Tage]" <time> (gPluggit) { channel="modbus:data:PluggitAP310:AP310_5:pluggit_prmFilterRemainingTime:number"}
Number Pluggit_BypassTemperatureMin "Min temperature for outdoor air (T1) [%.1f °C]" <temperature> (gPluggit) { channel="modbus:data:PluggitAP310:AP310_4:pluggit_prmBypassTmin:number"}
Number Pluggit_BypassTemperatureMax "Max temperature for extract air (T3) [%.1f °C]" <temperature> (gPluggit) { channel="modbus:data:PluggitAP310:AP310_4:pluggit_prmBypassTmax:number"}
Number Pluggit_BypassState "Bypass state [MAP(pluggit.map):BypassState_%s]" (gPluggit) { channel="modbus:data:PluggitAP310:AP310_1:pluggit_prmRamIdxBypassActualState:number"}
Number Pluggit_WeekProgram "Aktuelles Wochenprogramm [%d]" (gPluggit) { channel="modbus:data:PluggitAP310:AP310_4:pluggit_prmNumOfWeekProgram:number"}
This is a part of my sitemap:
Text icon="fan" label="Lüftung"
{
Text label="Time" icon="time"
{
Text item=Pluggit_CurrentUnixTime
Text item=Pluggit_WorkTimeOfSystem
Text item=Pluggit_StartExploitationUnixTime
Text item=Pluggit_RemainingFilerLivetime
}
Text label="General" icon="settings"
{
Text item=Pluggit_CurentUnitMode
Text item=Pluggit_PowerOfPreheater
Selection item=Pluggit_SpeedLevelOfFans mappings=[0="off", 1="1", 2="2", 3="3", 4="4" ]
Selection item=Pluggit_ActiveUnitMode mappings=[0="0Standby", 1="1Bypass", 4="4Manual Mode", 8="WeekProgram Mode", 16="Away Mode", 2052="Summer Mode"]
Text item=Pluggit_ActiveUnitMode
Text item=Pluggit_WeekProgram
Selection item=Pluggit_WeekProgram label="P3 zuhause, P10 weg" mappings=[2="P3, 10="P11"]
}
Text label="Temperature" icon="temperature"
{
Text item=Pluggit_OutdoorTemperature01
Text item=Pluggit_SupplyTemperature02
Text item=Pluggit_ExtractTemperature03
Text item=Pluggit_ExhaustTemperature04
}
Text label="Fans" icon="fan"
{
Text item=Pluggit_SpeedFan01
Text item=Pluggit_SpeedFan02
}
Text label="Bypass" icon="settings"
{
Text item=Pluggit_BypassTemperatureMin
Text item=Pluggit_BypassTemperatureMax
Text item=Pluggit_BypassState
}
}
I do not use more than these two weekprograms, as well the above listed Program Modes.
Hope that helps, good luck!
on openhab 2 I refered to a Pluggit.map within my item like this:
Number Pluggit_ActiveUnitMode "Active Mode [MAP(Pluggit.map):ActiveUnitMode_%s]" <settings> (gPluggit) { channel="modbus:data:PluggitAP310:prmRamIdxUnitMode:register:number" }
but it seems there is no map folder with *.map files anymore in openhab 3
I will give this one a try as well, thank you very much
There never was in OH2 either,it’s a folder /transform
MAP transformation remains the same; you must install the MAP add-on, you must create and put your own xxx.map files in the /transform folder.