having migratet to Openhab from FHEM i have issues with MAX! components. Having the CUBE added in openhab and having the things added (2 Thermostats, 1 Wall mounted Thermostat, 2 Window Shutter Contacts) i have no idea how to link them together. Aim should be to have the Wall monuted Thermostat be the “central” for the rest of the items, as it is one room here. So how do i tell openhab that a shuttercontact is associated with the thermostat?
You misunderstood that stuff. Associations are done inside MAX! using the MAX software. You can add openHAB items to make the devices visible in OH and to override settings from within OH, but you cannot associate these items in OH with each other.
You can choose to not associate the devices in MAX! and create OH rules (let’s say to sendCommand() to a thermostat when the shutter contact trigger), but that is something completely different and should not be called an ‘association’ to avoid further confusion.
alright, i understood that. So the most comfortable way to setup the whole max system for OH would be to use the MAX Software for configuration and then use OH to set temperature as needed?
I would like to try the send command version never the less, can someone give me a hint where to have a look in my case with the Max components?
Not sure you understood: the ‘send command version’ is one way to use OH to set temperatures, i.e. the answer to you question (and not ‘nevertheless’).
You configure devices using MAX!, you define OH items per PaperUI or file (see MAX! binding docs), then you can either use the (Classic or Basic) UI to change temperatures, or you write a rule if you want to automate that. The rule is where you would need to use the sendCommand().
A CUL is an 868MHz USB dongle that can replace the Cube using software like homegear. You can then use the homegear plugin for OpenHAB to control Max! devices. However, I am still stuck with the problem of linking devices like @Bastian_H so I am not sure if this can solve his problem.
what “problem” after all ?
I know it’s common for people migrating from FHEM where they used a CUL to expect OH to work the same way.
But a CUL is a FHEM concept and not an OH one. Don’t try migrating concepts, it just does not work out. Use the cube and the maxcube binding and you’re fine.
Yes there’s homegear, but you shouldn’t try getting that to work as an OH beginner, this is too big a jump and will lead to frustration. Retry in a year when you’ve got the rest working and feel comfortable with running OH but still really feel you need to get rid of the maxcube.
He wants changes on the Max! Wall Thermostat to be sent to the TRVs for a room rather than having to go to each valve and set the temperature there. For example, I have one room with three radiators, so I want to control all three from one location.
Thanks for your replies. So to make sure i got it all correctly, let me summarize:
To have multiple max components (things), communicate with each other in a way that makes sense for a room (shutter contact informs wall thermostat about an open window which then informs thermostats to close) i NEED to use the eq3 software, right?
With asking about the CUL i was referring to the fact, that the max cube can be flashed to be a CUL device and was asking myself if that would make working with max components easier.
No it won’t. It’s a way to get the stuff to work without a cube if you want that for whatever reason (be it valid or not, i.e. just to serve a dogma). It may work out, but for sure it won’t make life easier. It adds a lot of complexity, untestedness and all sorts of support issues that are to be expected whenever you leave the mainstream path. And it’s definitely nothing to recommend to any beginner.
I did as you told me and configured the basics with the eq3 software and already added them as things by Paper UI, thanks for that. Now working with Eclipse Designer for items and groups and already gotten far into making my whole house with this concept but i ran into some problem:
A Thermostat has 4 channels which you included in your item example. But, e.g., the batterylevel of a thermostate is a “switch”-type leading to a silly UI mess with the battery level beeing able to be “switched”… ofc it would make more sense that the battery icon is a state-icon and theres no switch ledger… how can that be done?
in your example you used 4 lines of code, each for one channel and one thing. is it possible to add several things to one line of code, e.g. several shutter contact´s batterylevel to the first line of of code starting with “switch maxbattery…” or do i have to use 4 lines of code for every thing?
Thanks for the massive help so far.
For the first the thermostat has 4 channels which are used in your example
I am quite far into items/Things/Sitemaps now and am about to configure the groups. Taking your example with the Window contact: isnt it possible to have one ITEM in a sitemap frame which displays multiple Channels? So i got an item for the Shutter contact telling me its open/closed AND if the battery is low…
I guess the week-programming still has to be done by eq3 Sofware?
the rules with weather and Astro is a nice idea, thanks for that, i will implement it when im done with everything else.
Another problem i ran into:
I put all the shutter contacts with the batterylow channel into a own group “gBatteries” in the item file. In Sitemap i owuld like a frame with all my battery states for all shutter contacts (13 in a total)… is there a way to display them all in one frame using the group or do i have to define 13 “Text items” in the sitemap? I tried it with “Text item=gBatteries” which didnt work out as the group is defined by "Group gBatteries “Batteriestatus” " which then is shown in the sitemap as one item, not all 13 contacts.