KNX weather station and shading review preview
The cross-check view keeps KNX source objects and generated Control4 structure visible together so wind, rain, brightness, blinds and feedback can be reviewed before export.
A weather station is not a normal user-facing device
KNX weather stations often publish several values and binary alarms: wind speed, rain, brightness, sun direction, temperature, frost, dusk or shading enable signals. Those values can influence blinds and awnings, but they are not the same as a simple Control4 light or shade.
The review layer should preserve the evidence from ETS so the installer can decide whether each signal becomes programming context, safety logic, an informational device, or an excluded item.
- Wind and rain should be treated as safety or protection context, not decorative labels.
- Brightness and sun values may influence shading scenes but need thresholds and local logic review.
- Temperature or frost values may cross into HVAC or weather display scope instead of the core build.
What to review in ETS before Composer
The ETS project should show which group addresses come from the weather station, what DPTs they use, whether the signals are binary alarms or numeric values, and which blinds or facade zones depend on them.
This is where a flat CSV or manual note often fails. The relationship between a wind alarm, a shading group and a blind position feedback can be hard to reconstruct after Composer devices have already been created.
- Wind alarm, wind speed and any reset or override object.
- Rain alarm and whether it locks awnings, windows or facade shading.
- Brightness/lux, sun elevation or facade-specific sun signals.
- Temperature, frost or dusk values used by scenes or schedules.
- Blind groups that should be protected or excluded from automatic movement.
Composer scope and device count boundary
The CoduWorks counted build stays focused on lights, blinds, thermostats and KNX IP gateways. Weather station values, sensors and protection objects do not move the license tier by themselves.
That boundary keeps the automatic build predictable. Weather signals can still be exported as clear review items or add-on scope so the installer can build the right Control4 programming intentionally.
Do not bypass KNX safety logic
If the KNX installation already protects awnings or blinds from wind, rain or frost, that logic should not be replaced casually in Composer. The first job is to understand which KNX objects represent protection, override and feedback.
A reviewed .codu package should make those signals visible, while the final safety and programming decisions remain with the installer and the official project documentation.
Official references checked
Technical claims on this page are kept close to official KNX, Control4, or manufacturer documentation.
Related tools and documentation
FAQ
Does CoduWorks auto-create KNX weather station devices in Control4?
No, not as part of the core build. Weather station values are review context or add-on/manual scope unless the installer confirms the intended Control4 representation.
Can weather station signals control KNX blinds in Control4?
They can be used as part of shading logic when DPTs, thresholds, protection behavior, gateway visibility and Composer programming are reviewed. Existing KNX safety logic should not be bypassed blindly.
Do wind, rain and sun sensors count for the license tier?
No. The counted device scope remains lights, blinds, thermostats and KNX IP gateways. Weather station signals are reviewed separately as context or add-on scope.
What should be checked before export?
Check weather station source device, DPTs, wind/rain alarms, brightness values, protected blind groups, feedback and whether any logic already exists in KNX.
Review weather and shading context before Composer
Import ETS, inspect weather station signals next to blinds and feedback, then export .codu only after the scope is clear.