connectorio / connectorio-addons Goto Github PK

View Code? Open in Web Editor NEW

18.0 4.0 11.0 5.75 MB

Dedicated repository for openHAB software extensions maintained by ConnectorIO.

License: Apache License 2.0

Java 100.00%

beckhoff-twincat-plc siemens-s7-plcs bacnet canopen openhab3 openhab

connectorio-addons's People

Contributors

Stargazers

Watchers

Forkers

brzd dostaigo angviza chillr21 picomass uspringis bverburg raf1000 ibpiotr inailuig cdjackson

connectorio-addons's Issues

canopen.ta CAN input channel not created if unit is automatic

Issue opened to document the current way of handling units by the binding:

In case the CAN input is set to automatic the following error prevents the channel creation in case the unit of the CAN input is set to automatic on TA hardware.

[INFO ] [DefaultChannelFactory] - Ignoring analog I/O object TAAnalogInput[1] unit=-1, name=TACanString(CAN AI 1) [220f, 0], configuredUnit=-1 object. **Could not find matching channel and thing for unit -1**

Currently only workaround is to set a specific unit type for CAN input in TA hardware.

[WM-Bus] Add support for TCH Hardwareversion 57 device (Heat_Meter?)

This device is recognized as OTHER. If manually set to HEAT_METER it wants an encryption key, but in my case this device sends without encryption. This could not be changed (Encryption), so no chance to get this working.

Its a Kamstrup multical21 Device I believe. There are so many distributors for same device.

Provide inspector which will trace communication between bindings and end devices

There are cases where data follows asymmetric paths (listening for radio broadcasts, packets generated by operation in binding) which might result in various hard-to-follow situations. Usually low level tracing requires use of wireshark or specialized tooling. A software communication inspector which could be feed and utilized by bindings will help in collecting traces.

Support for rewriting calls to https servers through proxy module

The http proxy module currently do not support https targets. For experimentation purposes it could began supporting it.

Provide KAR files for serial port utilities

The purejavacomm serial provider is used as drop-in replacement for some issues which are happening with rxtx. Making it available for wider community will simplify people's life.

(in relation to https://community.openhab.org/t/oh3-x-oh4-x-alternative-java-serial-provider/128462/34)

Support wireless m-bus for openHAB 4.0.3

Happy to get feedback if someone else uses 4.0.3 and wmbus :-)

Add rollershutters for fatek binding

Please add rollershuter function for fatek binding (openhab3)

Automatic discovery of ADS symbols / channels

Some of Beckhoff devices based on ADS protocol offers possibility to fetch "symbol table". Symbol table consist name of tag/data point, its type and several other flags. This information can be used to provision channels within discovered and connected PLCs things reducing commisioning time to minimum.

Example symbol table retrieved from TwinCAT/BSD virtual machine running empty PLC program:

      |           PLC4X Field         |          Hex          |                                                            
##### |          Query Syntax         |   Index   |   Offset  |    Type   | Name                                   | Size (B) | Type | Value (type)
------+-------------------------------+-----------+-----------+-----------+----------------------------------------+----------+------|
    0 |           0x4040/0x5dffd:BOOL |    0x4040 |   0x5dffd |      BOOL |Constants.bFPUSupport                   |        1 |   33 | true (java.lang.Boolean)
    2 |           0x4040/0x5dfeb:BOOL |    0x4040 |   0x5dfeb |      BOOL |Constants.bLittleEndian                 |        1 |   33 | true (java.lang.Boolean)
    4 |           0x4040/0x5e002:BOOL |    0x4040 |   0x5e002 |      BOOL |Constants.bMulticoreSupport             |        1 |   33 | false (java.lang.Boolean)
    6 |           0x4040/0x5dffc:BOOL |    0x4040 |   0x5dffc |      BOOL |Constants.bSimulationMode               |        1 |   33 | false (java.lang.Boolean)
    8 |        0x4040/0x5dff4:VERSION |    0x4040 |   0x5dff4 |   VERSION |Constants.CompilerVersion               |        8 |   65 | {uiMajor=3, uiMinor=5, uiServicePack=13, uiPatch=40} (java.util.Map)
   10 |          0x4040/0x5e008:DWORD |    0x4040 |   0x5e008 |     DWORD |Constants.CompilerVersionNumeric        |        4 |   19 | 50662696 (java.lang.Long)
   12 |           0x4040/0x5e000:UINT |    0x4040 |   0x5e000 |      UINT |Constants.nPackMode                     |        2 |   18 | 8 (java.lang.Integer)
   14 |           0x4040/0x5dffe:WORD |    0x4040 |   0x5dffe |      WORD |Constants.nRegisterSize                 |        2 |   18 | 64 (java.lang.Integer)
   16 |        0x4040/0x5dfec:VERSION |    0x4040 |   0x5dfec |   VERSION |Constants.RuntimeVersion                |        8 |   65 | {uiMajor=3, uiMinor=5, uiServicePack=13, uiPatch=0} (java.util.Map)
   18 |          0x4040/0x5e004:DWORD |    0x4040 |   0x5e004 |     DWORD |Constants.RuntimeVersionNumeric         |        4 |   19 | 50662656 (java.lang.Long)

canopen.ta: Values transmitted on canbus are not stable

Although value in OH is not changed the value transported on canbus is instable.
Example:
(2021-08-18 10:15:46.506018) can0 202 [8] B2 00 00 00 00 00 00 00
(2021-08-18 10:15:56.574312) can0 202 [8] 00 00 00 00 00 00 00 00
(2021-08-18 10:16:46.534185) can0 202 [8] B2 00 00 00 00 00 00 00

Sending the "00" value seems to happen exactly 10 seconds after real value is sent consequently nullifying all awaited values at destination nodes.

Provide KAR files for debounce and other profiles

Publish profiles so they can be utilized externally.

(in relation to https://community.openhab.org/t/reducing-item-updates-and-thus-log-entries-caused-by-a-modbus-tcp-energy-meter/146516/14)

[WM-Bus] Add support for TCH Hardwareversion 23 device (Heat_Meter)

This device always shows decryption error with (securely and moretimes checked) right AES keys, working with other wmbus-solutions.

Invalid behavior of amsads binding with Beckhoff BX9000

Reported here:
https://community.openhab.org/t/co7io-industrial-integrations-with-beckhoff-ads-siemens-s7/89021/82

The BX9000 does not support symbolic addresses, hence it should not be scanned for these.

09:45:29.812 [INFO ] [hab.event.ThingStatusInfoChangedEvent] - Thing 'co7io-amsads:network:192_168_7_10_1_1:192_168_7_21' changed from INITIALIZING to UNKNOWN
09:45:30.635 [INFO ] [hab.event.ThingStatusInfoChangedEvent] - Thing 'co7io-amsads:network:192_168_7_10_1_1:192_168_7_21' changed from UNKNOWN to OFFLINE (HANDLER_INITIALIZING_ERROR): Could not retrieve data type and symbol information from ADS device org.apache.plc4x.java.api.exceptions.PlcException: Result is null
09:45:47.010 [ERROR] [.connection.DefaultNettyPlcConnection] - unknown error, close the connection
java.net.SocketException: Connection reset
	at sun.nio.ch.SocketChannelImpl.throwConnectionReset(SocketChannelImpl.java:394) ~[?:?]
	at sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:426) ~[?:?]
	at io.netty.buffer.PooledByteBuf.setBytes(PooledByteBuf.java:256) ~[?:?]
	at io.netty.buffer.AbstractByteBuf.writeBytes(AbstractByteBuf.java:1132) ~[?:?]
	at io.netty.channel.socket.nio.NioSocketChannel.doReadBytes(NioSocketChannel.java:357) ~[?:?]
	at io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:151) ~[?:?]
	at io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:788) ~[?:?]
	at io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:724) ~[?:?]
	at io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:650) ~[?:?]
	at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:562) ~[?:?]
	at io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:997) ~[?:?]
	at io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74) ~[?:?]
	at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30) ~[?:?]
	at java.lang.Thread.run(Thread.java:840) ~[?:?]

Iconify support for openHAB 4

Add support for Openhab 4 - specifically org.connectorio.addons.ui.iconify

Reduce verbosibility of logging

Tracking issue for cleanups of log entries which can be tweaked to reduce output or align information produced to log.

Eliminate use o ThreadLocal in chained profiles

The chained profile concept outlined in opensmarthouse/opensmarthouse-core#35 which was supplied in this repository have been implemented in 2021 and quickly redesigned in 2022. First and redesigned implementation embedded ThreadLocal to pass invocation which initially worked well.
However, this design have a large drawback of retaining invocation state within a shared object. The main point of it was really to separate creation and invocation time, which could not be shared.

Looking closer at the issue of sharing state, it actually can be bridged between creation and invocation time without ThreadLocal and major multi threading risks. When invocation chain is initialized, chain elements are initialized sequentially. It means that they know own position and can reference chain. In order to simplify invocation, we can also swap use of iterator and rely on chain element index manipulation (+1 from handler to item, -1 from item to handler), in order to avoid direct references.

While I know it sounds very complex, actual change (despite of its size) will result in much simpler code providing the same functionality.

Fatek serial connection support

Old binding for openHAB supported serial connectivity. Backported functionality should include it.

Wireless M-Bus binding keeps discarding chunk of data

following io-bundles installed and active (searched for .io.):

169 x Active x  80 x 4.0.3                  x org.openhab.core.io.console.karaf
170 x Active x  80 x 4.0.3                  x org.openhab.core.io.http
171 x Active x  80 x 4.0.3                  x org.openhab.core.io.http.auth
173 x Active x  80 x 4.0.3                  x org.openhab.core.io.monitor
174 x Active x  80 x 4.0.3                  x org.openhab.core.io.net
175 x Active x  80 x 4.0.3                  x org.openhab.core.io.rest
176 x Active x  80 x 4.0.3                  x org.openhab.core.io.rest.audio
177 x Active x  80 x 4.0.3                  x org.openhab.core.io.rest.auth
178 x Active x  80 x 4.0.3                  x org.openhab.core.io.rest.core
179 x Active x  80 x 4.0.3                  x org.openhab.core.io.rest.mdns
180 x Active x  80 x 4.0.3                  x org.openhab.core.io.rest.sitemap
181 x Active x  80 x 4.0.3                  x org.openhab.core.io.rest.sse
182 x Active x  80 x 4.0.3                  x org.openhab.core.io.rest.swagger
183 x Active x  80 x 4.0.3                  x org.openhab.core.io.rest.transform
184 x Active x  80 x 4.0.3                  x org.openhab.core.io.rest.ui
185 x Active x  80 x 4.0.3                  x org.openhab.core.io.rest.voice
186 x Active x  80 x 4.0.3                  x org.openhab.core.io.transport.mdns
187 x Active x  80 x 4.0.3                  x org.openhab.core.io.websocket
296 x Active x  80 x 4.0.3                  x org.openhab.core.io.transport.modbus
297 x Active x  80 x 4.0.3                  x org.openhab.core.io.transport.mqtt
298 x Active x  80 x 4.0.3                  x org.openhab.core.io.transport.serial
299 x Active x  80 x 4.0.3                  x org.openhab.core.io.transport.serial.rxtx
300 x Active x  80 x 4.0.3                  x org.openhab.core.io.transport.serial.rxtx.rfc2217
301 x Active x  80 x 4.0.3                  x org.openhab.core.io.transport.upnp

binding gives following output in debug mode:

2023-07-01 16:28:53.770 [DEBUG] [ransport.WMBusMessageListenerAdapter] - Discarding chunk of data stream containing 12 bytes
2023-07-01 16:28:55.802 [DEBUG] [ransport.WMBusMessageListenerAdapter] - Discarding chunk of data stream containing 12 bytes
2023-07-01 16:29:28.675 [DEBUG] [ransport.WMBusMessageListenerAdapter] - Discarding chunk of data stream containing 13 bytes
2023-07-01 16:29:33.682 [DEBUG] [ransport.WMBusMessageListenerAdapter] - Discarding chunk of data stream containing 1 bytes
2023-07-01 16:29:33.780 [DEBUG] [ransport.WMBusMessageListenerAdapter] - Discarding chunk of data stream containing 100 bytes
2023-07-01 16:29:43.601 [DEBUG] [ransport.WMBusMessageListenerAdapter] - Discarding chunk of data stream containing 3 bytes
2023-07-01 16:29:48.608 [DEBUG] [ransport.WMBusMessageListenerAdapter] - Discarding chunk of data stream containing 6 bytes
2023-07-01 16:29:48.721 [DEBUG] [ransport.WMBusMessageListenerAdapter] - Discarding chunk of data stream containing 100 bytes
2023-07-01 16:29:51.071 [DEBUG] [ransport.WMBusMessageListenerAdapter] - Discarding chunk of data stream containing 9 bytes
2023-07-01 16:29:59.709 [DEBUG] [ransport.WMBusMessageListenerAdapter] - Discarding chunk of data stream containing 1 bytes
2023-07-01 16:30:13.627 [DEBUG] [ransport.WMBusMessageListenerAdapter] - Discarding chunk of data stream containing 14 bytes
2023-07-01 16:30:14.678 [DEBUG] [ransport.WMBusMessageListenerAdapter] - Discarding chunk of data stream containing 0 bytes```

wmbus stick is following AMB8465-M

[WM-Bus] Water meters sometimes went offline "wrong keys"

Device got already actual data went suddenly to offline "wrong keys". Save configuration (change in label eg) let it come online again

Maybe only a onetime issue, if no further notices like this could be closed again.

Devices shown online in openhab while linked bridge (serial-jrxtx) is offline with error could not open port

If the bridge is offline, the devices should show bridge not available instead of being online

Support for prioritized writes within BACnet device channels

Spotted that while preparing documentation updates - priorities are available only when given BACnet object is represented by a Thing. This means that object channels defined within ip-device or mstp-device are always written using default priority.

Support bacnet for openHAB 4.0.x

Dear Splash, as "wished",

opening a ticket for BACnet support in OH4.. Thnik it makes sense to start with the newes stable version of OH

canopen DBUS scan error on rpi

On start of first OH thing using canopen addon this error occurs on debian on raspberry pi as the required NetworkManager is not present in this environment.

[ERROR] [DBusCANInterfaceDiscoveryService] - Discovery of can interfaces via dbus failed org.freedesktop.dbus.errors.ServiceUnknown: The name org.freedesktop.NetworkManager was not provided by any .service files

Compiling for OH4

Hey @splatch - as discussed elsewhere, I've pulled the 4.1.x branch, but it doesn't build -:

[ERROR] [ERROR] Some problems were encountered while processing the POMs:
[FATAL] Non-resolvable parent POM for org.connectorio:addons:4.1.0-SNAPSHOT: The following artifacts could not be resolved: org.connectorio:connectorio-oss:pom:5-SNAPSHOT (absent): org.connectorio:connectorio-oss:pom:5-SNAPSHOT was not found in https://repo1.maven.org/maven2 during a previous attempt. This failure was cached in the local repository and resolution is not reattempted until the update interval of central has elapsed or updates are forced and 'parent.relativePath' points at no local POM @ line 23, column 11

I've tried the -Popenhab,thing4 option but this didn't help....

Thanks.

ta_device reload config does not change channels

I replaced the program on the TA hardware by a new one with different CAN inputs and outputs.
The binding reloaded data from the TA hardware after "reload" was set, but did not create new / changed channel objects.

Removing binding and recreating it new did the job and instanced all CAN inputs and outputs .

connectorio / connectorio-addons Goto Github PK

connectorio-addons's People

Contributors

Stargazers

Watchers

Forkers

connectorio-addons's Issues

Recommend Projects

Recommend Topics

Recommend Org

Jobs