openHAB 4.0 SNAPSHOT discussion

Why is that? Did you use the metadata.json I send to your email?

I just tried it in the old system, but there I couldn’t run the script. I will try it in the new system later on. What I forgot to say, that all units from z-wave devices are gone except for temperature . There is not Voltage „V“ for electric.potential

The world is ok again. I copied the metadata.json file and it works ok. Thanks a lot.

1 Like

I made my first foray into openHAB 4 today. I loaded the SNAPSHOT 3842 using openhabian. I had previously updated to Java 17. It appears to have gone fairly smoothly.

The biggest obvious problem I experienced was when I went to add the smart home/j Tuya and AmazonEchoControl bindings. When I first went to the Add-on’s screen in the UI, the smarthome/j bindings were listed after the Community Bindings. A little while after I clicked on install on the AmazonEchoControl and Tuya bindings, there was an error message in the lower left hand corner. It didn’t stay, so I’m going from memory but it was something about JSON file error. After that, the smarthome/j bindings disappeared front the UI. I tried restarting openHAB, but that didn’t help.

I poked around looking for things that looked amiss. There are some references to 3.4 that seem out of place in:


openhabian@openhabian-spring:/var/lib/openhab/config/smarthomej $ cat AddonProvider.config
:org.apache.felix.configadmin.revision:=L"73"
installedAddons="smarthomej-binding-amazonechocontrol_3_2_4"
installedFeatureRepos="mvn:org.smarthomej.addons.features.karaf/org.smarthomej.addons.features.karaf.smarthomej-addons/3.2.4/xml/features"
service.pid="smarthomej.AddonProvider"


runtimeInfo:
  version: 4.0.0
  buildString: "Build #3482"
locale: en-US
systemInfo:
  configFolder: /etc/openhab
  userdataFolder: /var/lib/openhab
  logFolder: /var/log/openhab
  javaVersion: 17.0.6
  javaVendor: Raspbian
  osName: Linux
  osVersion: 6.1.21-v8+
  osArchitecture: arm
  availableProcessors: 4
  freeMemory: 34531208
  totalMemory: 259522560
  startLevel: 70
bindings: null
clientInfo:
  device:
    ios: true
    android: false
    androidChrome: false
    desktop: false
    iphone: false
    ipod: false
    ipad: true
    edge: false
    ie: false
    firefox: false
    macos: false
    windows: false
    cordova: false
    phonegap: false
    electron: false
    nwjs: false
    os: ios
    osVersion: "16.1"
    webView: false
    webview: false
    standalone: false
    pixelRatio: 2
    prefersColorScheme: light
  isSecureContext: false
  locationbarVisible: true
  menubarVisible: true
  navigator:
    cookieEnabled: true
    deviceMemory: N/A
    hardwareConcurrency: 7
    language: en-US
    languages:
      - en-US
    onLine: true
    platform: MacIntel
  screen:
    width: 1024
    height: 1366
    colorDepth: 32
  support:
    touch: true
    pointerEvents: true
    observer: true
    passiveListener: true
    gestures: true
    intersectionObserver: true
  themeOptions:
    dark: light
    filled: true
    pageTransitionAnimation: default
    bars: light
    homeNavbar: default
    homeBackground: default
    expandableCardAnimation: default
  userAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15
    (KHTML, like Gecko) Version/16.1 Safari/605.1.15
timestamp: 2023-05-28T23:05:29.155Z

I have a few rules I need to sort out. I thought I went through and opened all of my Blocklies and saved them, but I’m still getting a few Errors.


2023-05-28 18:12:29.454 [ERROR] [ipt.internal.ScriptEngineManagerImpl] - ScriptEngine for language 'application/javascript' could not be found for identifier: dd9beff2-1ccc-4b81-bac0-456fd51c723e
2023-05-28 18:12:29.513 [ERROR] [ipt.internal.ScriptEngineManagerImpl] - ScriptEngine for language 'application/javascript' could not be found for identifier: 26aebbf6-1481-4b97-b875-dba3d20e5f41
2023-05-28 18:12:29.514 [ERROR] [ipt.internal.ScriptEngineManagerImpl] - ScriptEngine for language 'application/javascript' could not be found for identifier: dbafca86-c651-4184-b303-9e7100185542
2023-05-28 18:12:29.518 [ERROR] [ipt.internal.ScriptEngineManagerImpl] - ScriptEngine for language 'application/javascript' could not be found for identifier: dbafca86-c651-4184-b303-9e7100185542

I can’t connect the identifier to anything that would help me figure out which rule is causing the error. Is there some way to do that I’m missing?

Sorry for the slow reply - I never saw your edit. But anyhow, I figured it out today. I was wrongly assuming that if you don’t have the unit metadata set, it would infer the unit from the state description. As for my debugging… I found a bug in the Ruby helper library that unit is possibly calling the wrong method. So yeah, I think it was just a few things wrong on my end, and it seems to be working now. Thanks!

openHabian clean install on rpi4 OH4.0.0 #3483 with just EnOcean binding installed.

EnOcean USB300 dongle is automatically put to inbox with correct port.
The port is available and working.
But after adding thing “trying to get bridge base id …” does not work.

2023-05-29 09:53:19.298 [INFO ] [ernal.transceiver.EnOceanTransceiver] - EnOceanSerialTransceiver initialized

2023-05-29 09:53:19.300 [INFO ] [ernal.transceiver.EnOceanTransceiver] - EnOceanSerialTransceiver RX thread started

==> /var/log/openhab/events.log <==

2023-05-29 09:53:19.300 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'enocean:bridge:FT3OLRGB' changed from OFFLINE (CONFIGURATION_PENDING): opening serial port... to OFFLINE (CONFIGURATION_PENDING): starting rx thread...

==> /var/log/openhab/openhab.log <==

2023-05-29 09:53:19.301 [INFO ] [nternal.handler.EnOceanBridgeHandler] - EnOceanSerialTransceiver RX thread up and running

==> /var/log/openhab/events.log <==

2023-05-29 09:53:19.304 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'enocean:bridge:FT3OLRGB' changed from OFFLINE (CONFIGURATION_PENDING): starting rx thread... to OFFLINE (CONFIGURATION_PENDING): trying to get bridge base id...

Do you have the JavaScript Scripting add-on installed?

1 Like

No, I did not. Installing it appears to have resolved that problem. Thanks.

1 Like

Regarding enocean binding, I can find 3 changes in 2023:

EnOcean USB300 dongle “trying to get bridge base id …” does not work

It was reported to be working with OH 4.0.0.M1, but broken on OH 4.0.0.M2 and M3 …

I tested it with OH 4.0.0.M3 and OH4.0.0 #3483. Both show the error on a clean rpi4 openHABian install.

The thing status does not change afterwards? Can you set log:set TRACE org.openhab.binding.enocean on the karaf console and disable/enable the thing again? You can revert that log setting by exchanging TRACE with DEFAULT.

Please find below the logs with OH 4.0.0.M3:

2023-05-29 15:06:10.699 [INFO ] [g.discovery.internal.PersistentInbox] - Added new thing 'enocean:bridge:FT3OLRGB' to inbox.
2023-05-29 15:07:11.423 [INFO ] [ernal.transceiver.EnOceanTransceiver] - EnOceanSerialTransceiver initialized
2023-05-29 15:07:11.427 [INFO ] [ernal.transceiver.EnOceanTransceiver] - EnOceanSerialTransceiver RX thread started
2023-05-29 15:07:11.430 [INFO ] [nternal.handler.EnOceanBridgeHandler] - EnOceanSerialTransceiver RX thread up and running
2023-05-29 15:07:11.434 [DEBUG] [nternal.handler.EnOceanBridgeHandler] - request base id
2023-05-29 15:07:11.441 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - Enqueue new send request with ESP3 type COMMON_COMMAND with callback
2023-05-29 15:07:11.444 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - Sending data, type COMMON_COMMAND, payload 08
2023-05-29 15:07:11.446 [TRACE] [ernal.transceiver.EnOceanTransceiver] - Sending raw data: 5500010005700838
2023-05-29 15:07:11.451 [DEBUG] [nternal.handler.EnOceanBridgeHandler] - set postmaster mailboxes
2023-05-29 15:07:11.453 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - Enqueue new send request with ESP3 type SMART_ACK_COMMAND with callback
2023-05-29 15:07:11.455 [DEBUG] [nternal.handler.EnOceanBridgeHandler] - request version info
2023-05-29 15:07:11.457 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - Enqueue new send request with ESP3 type COMMON_COMMAND with callback
2023-05-29 15:07:11.701 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - Sending data, type SMART_ACK_COMMAND, payload 0814
2023-05-29 15:07:11.702 [TRACE] [ernal.transceiver.EnOceanTransceiver] - Sending raw data: 5500020006C40814C4
2023-05-29 15:07:11.963 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - Sending data, type COMMON_COMMAND, payload 03
2023-05-29 15:07:11.965 [TRACE] [ernal.transceiver.EnOceanTransceiver] - Sending raw data: 5500010005700309
2023-05-29 15:07:57.478 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - shutting down transceiver
2023-05-29 15:07:57.479 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - Interrupt rx Thread
2023-05-29 15:07:57.481 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - Closing the serial port
2023-05-29 15:07:57.515 [INFO ] [ernal.transceiver.EnOceanTransceiver] - Transceiver shutdown
2023-05-29 15:08:09.476 [INFO ] [ernal.transceiver.EnOceanTransceiver] - EnOceanSerialTransceiver initialized
2023-05-29 15:08:09.479 [INFO ] [ernal.transceiver.EnOceanTransceiver] - EnOceanSerialTransceiver RX thread started
2023-05-29 15:08:09.480 [INFO ] [nternal.handler.EnOceanBridgeHandler] - EnOceanSerialTransceiver RX thread up and running
2023-05-29 15:08:09.482 [DEBUG] [nternal.handler.EnOceanBridgeHandler] - request base id
2023-05-29 15:08:09.484 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - Enqueue new send request with ESP3 type COMMON_COMMAND with callback
2023-05-29 15:08:09.488 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - Sending data, type COMMON_COMMAND, payload 08
2023-05-29 15:08:09.489 [TRACE] [ernal.transceiver.EnOceanTransceiver] - Sending raw data: 5500010005700838
2023-05-29 15:08:09.493 [DEBUG] [nternal.handler.EnOceanBridgeHandler] - set postmaster mailboxes
2023-05-29 15:08:09.494 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - Enqueue new send request with ESP3 type SMART_ACK_COMMAND with callback
2023-05-29 15:08:09.496 [DEBUG] [nternal.handler.EnOceanBridgeHandler] - request version info
2023-05-29 15:08:09.497 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - Enqueue new send request with ESP3 type COMMON_COMMAND with callback
2023-05-29 15:08:09.743 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - Sending data, type SMART_ACK_COMMAND, payload 0814
2023-05-29 15:08:09.745 [TRACE] [ernal.transceiver.EnOceanTransceiver] - Sending raw data: 5500020006C40814C4
2023-05-29 15:08:10.001 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - Sending data, type COMMON_COMMAND, payload 03
2023-05-29 15:08:10.003 [TRACE] [ernal.transceiver.EnOceanTransceiver] - Sending raw data: 5500010005700309
2023-05-29 15:08:11.460 [WARN ] [.core.thing.binding.BaseThingHandler] - Handler EnOceanBridgeHandler tried updating the thing status although the handler was already disposed.
2023-05-29 15:08:11.498 [WARN ] [.core.thing.binding.BaseThingHandler] - Handler EnOceanBridgeHandler tried updating the thing status although the handler was already disposed.
2023-05-29 15:09:09.500 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - shutting down transceiver
2023-05-29 15:09:09.502 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - Interrupt rx Thread
2023-05-29 15:09:09.504 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - Closing the serial port
2023-05-29 15:09:09.548 [INFO ] [ernal.transceiver.EnOceanTransceiver] - Transceiver shutdown
2023-05-29 15:09:09.578 [INFO ] [ernal.transceiver.EnOceanTransceiver] - EnOceanSerialTransceiver initialized
2023-05-29 15:09:09.584 [INFO ] [ernal.transceiver.EnOceanTransceiver] - EnOceanSerialTransceiver RX thread started
2023-05-29 15:09:09.586 [INFO ] [nternal.handler.EnOceanBridgeHandler] - EnOceanSerialTransceiver RX thread up and running
2023-05-29 15:09:09.588 [DEBUG] [nternal.handler.EnOceanBridgeHandler] - request base id
2023-05-29 15:09:09.591 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - Enqueue new send request with ESP3 type COMMON_COMMAND with callback
2023-05-29 15:09:09.596 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - Sending data, type COMMON_COMMAND, payload 08
2023-05-29 15:09:09.598 [TRACE] [ernal.transceiver.EnOceanTransceiver] - Sending raw data: 5500010005700838
2023-05-29 15:09:09.603 [DEBUG] [nternal.handler.EnOceanBridgeHandler] - set postmaster mailboxes
2023-05-29 15:09:09.605 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - Enqueue new send request with ESP3 type SMART_ACK_COMMAND with callback
2023-05-29 15:09:09.607 [DEBUG] [nternal.handler.EnOceanBridgeHandler] - request version info
2023-05-29 15:09:09.609 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - Enqueue new send request with ESP3 type COMMON_COMMAND with callback
2023-05-29 15:09:09.853 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - Sending data, type SMART_ACK_COMMAND, payload 0814
2023-05-29 15:09:09.856 [TRACE] [ernal.transceiver.EnOceanTransceiver] - Sending raw data: 5500020006C40814C4
2023-05-29 15:09:10.115 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - Sending data, type COMMON_COMMAND, payload 03
2023-05-29 15:09:10.118 [TRACE] [ernal.transceiver.EnOceanTransceiver] - Sending raw data: 5500010005700309
2023-05-29 15:09:11.502 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - shutting down transceiver
2023-05-29 15:09:11.504 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - Interrupt rx Thread
2023-05-29 15:09:11.506 [INFO ] [ernal.transceiver.EnOceanTransceiver] - Transceiver shutdown
2023-05-29 15:09:11.508 [WARN ] [.core.thing.binding.BaseThingHandler] - Handler EnOceanBridgeHandler tried updating the thing status although the handler was already disposed.
2023-05-29 15:09:11.544 [WARN ] [.core.thing.binding.BaseThingHandler] - Handler EnOceanBridgeHandler tried updating the thing status although the handler was already disposed.
22023-05-29 15:10:09.611 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - shutting down transceiver
2023-05-29 15:10:09.614 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - Interrupt rx Thread
2023-05-29 15:10:09.618 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - Closing the serial port
2023-05-29 15:10:09.650 [INFO ] [ernal.transceiver.EnOceanTransceiver] - Transceiver shutdown
2023-05-29 15:10:09.680 [INFO ] [ernal.transceiver.EnOceanTransceiver] - EnOceanSerialTransceiver initialized
2023-05-29 15:10:09.682 [INFO ] [ernal.transceiver.EnOceanTransceiver] - EnOceanSerialTransceiver RX thread started
2023-05-29 15:10:09.686 [INFO ] [nternal.handler.EnOceanBridgeHandler] - EnOceanSerialTransceiver RX thread up and running
2023-05-29 15:10:09.691 [DEBUG] [nternal.handler.EnOceanBridgeHandler] - request base id
2023-05-29 15:10:09.694 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - Enqueue new send request with ESP3 type COMMON_COMMAND with callback
2023-05-29 15:10:09.696 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - Sending data, type COMMON_COMMAND, payload 08
2023-05-29 15:10:09.699 [TRACE] [ernal.transceiver.EnOceanTransceiver] - Sending raw data: 5500010005700838
2023-05-29 15:10:09.709 [DEBUG] [nternal.handler.EnOceanBridgeHandler] - set postmaster mailboxes
2023-05-29 15:10:09.712 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - Enqueue new send request with ESP3 type SMART_ACK_COMMAND with callback
2023-05-29 15:10:09.713 [DEBUG] [nternal.handler.EnOceanBridgeHandler] - request version info
2023-05-29 15:10:09.716 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - Enqueue new send request with ESP3 type COMMON_COMMAND with callback
2023-05-29 15:10:09.960 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - Sending data, type SMART_ACK_COMMAND, payload 0814
2023-05-29 15:10:09.962 [TRACE] [ernal.transceiver.EnOceanTransceiver] - Sending raw data: 5500020006C40814C4
2023-05-29 15:10:10.217 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - Sending data, type COMMON_COMMAND, payload 03
2023-05-29 15:10:10.219 [TRACE] [ernal.transceiver.EnOceanTransceiver] - Sending raw data: 5500010005700309
2023-05-29 15:10:11.547 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - shutting down transceiver
2023-05-29 15:10:11.549 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - Interrupt rx Thread
2023-05-29 15:10:11.551 [INFO ] [ernal.transceiver.EnOceanTransceiver] - Transceiver shutdown
2023-05-29 15:10:11.553 [WARN ] [.core.thing.binding.BaseThingHandler] - Handler EnOceanBridgeHandler tried updating the thing status although the handler was already disposed.
2023-05-29 15:10:11.582 [WARN ] [.core.thing.binding.BaseThingHandler] - Handler EnOceanBridgeHandler tried updating the thing status although the handler was already disposed.
22023-05-29 15:11:09.718 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - shutting down transceiver
2023-05-29 15:11:09.720 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - Interrupt rx Thread
2023-05-29 15:11:09.722 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - Closing the serial port
2023-05-29 15:11:09.780 [INFO ] [ernal.transceiver.EnOceanTransceiver] - Transceiver shutdown
2023-05-29 15:11:09.810 [INFO ] [ernal.transceiver.EnOceanTransceiver] - EnOceanSerialTransceiver initialized
2023-05-29 15:11:09.814 [INFO ] [ernal.transceiver.EnOceanTransceiver] - EnOceanSerialTransceiver RX thread started
2023-05-29 15:11:09.816 [INFO ] [nternal.handler.EnOceanBridgeHandler] - EnOceanSerialTransceiver RX thread up and running
2023-05-29 15:11:09.819 [DEBUG] [nternal.handler.EnOceanBridgeHandler] - request base id
2023-05-29 15:11:09.821 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - Enqueue new send request with ESP3 type COMMON_COMMAND with callback
2023-05-29 15:11:09.825 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - Sending data, type COMMON_COMMAND, payload 08
2023-05-29 15:11:09.830 [TRACE] [ernal.transceiver.EnOceanTransceiver] - Sending raw data: 5500010005700838
2023-05-29 15:11:09.840 [DEBUG] [nternal.handler.EnOceanBridgeHandler] - set postmaster mailboxes
2023-05-29 15:11:09.842 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - Enqueue new send request with ESP3 type SMART_ACK_COMMAND with callback
2023-05-29 15:11:09.844 [DEBUG] [nternal.handler.EnOceanBridgeHandler] - request version info
2023-05-29 15:11:09.845 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - Enqueue new send request with ESP3 type COMMON_COMMAND with callback
2023-05-29 15:11:10.090 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - Sending data, type SMART_ACK_COMMAND, payload 0814
2023-05-29 15:11:10.092 [TRACE] [ernal.transceiver.EnOceanTransceiver] - Sending raw data: 5500020006C40814C4
2023-05-29 15:11:10.348 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - Sending data, type COMMON_COMMAND, payload 03
2023-05-29 15:11:10.349 [TRACE] [ernal.transceiver.EnOceanTransceiver] - Sending raw data: 5500010005700309
2023-05-29 15:11:11.585 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - shutting down transceiver
2023-05-29 15:11:11.587 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - Interrupt rx Thread
2023-05-29 15:11:11.588 [INFO ] [ernal.transceiver.EnOceanTransceiver] - Transceiver shutdown
2023-05-29 15:11:11.591 [WARN ] [.core.thing.binding.BaseThingHandler] - Handler EnOceanBridgeHandler tried updating the thing status although the handler was already disposed.
2023-05-29 15:11:11.622 [WARN ] [.core.thing.binding.BaseThingHandler] - Handler EnOceanBridgeHandler tried updating the thing status although the handler was already disposed.

I’ve opened a new issue against the Main UI, however I’m concerned it’s related to the core and not the UI itself (specifically with how/when the addon is loaded). Addons where a jar is put into the addons folder show up without issues when trying to manually add a thing on the UI. Addons pulled in from the marketplace don’t have any option to manually add a thing with the error “No thing types can be added with this binding.” I have this happening across all 3 of the bindings I have in the marketplace right now, I just used Ring as an example.

Just checked with Webex Binding, which lets me add an account thing manually.
So it seems not to be a UI or core bug, but a binding issue.

Interesting. Do the jars get loaded at a different time between the two? I did my tests with the exact same jar file. Not sure why it would work on one and fail on the other.

Is there an addon.xml in the jar?

Yes. There is actually both addon and binding on those for compatibility in the marketplace.

I’m not sure if this is fixed as part of the upgrade tool or not. You might need to delete the org.openhab.marketplace.json file from the jsondb folder (and the backup folder if it’s there) and let OH recreate it.

I recommend going forward, when you create a rule always change the randomly generated uid with something meaningful. For these, search for the rule id on the rules page. Search works on the names and the ids. Search in the developer sidebar should work too.

It might be a Script too so search there also. But the root problem, as you found is the add-on isn’t installed.

After upgrading 3.4.4->4.0 (S3515 currently), I keep seeing messages like these for several UoM items, this one Netzeinspeisung is a Number:Power.
At times it’s updated multiple times in a second. Seems I am only getting the message for some updates, not all of them.
Cannot make sense of that so far.
Is that related to what you referred to in your post openHAB 4.0 SNAPSHOT discussion - #342 by J-N-K?

[WARN ] [stence.rrd4j.internal.RRD4jPersistenceService] - RRD4J does not support adding past value this=1688062278, last update=1688062279. Discarding Netzeinspeisung - -0.2776104727224245

I don’t think it has anything to do with UoM. I’ve been seeing these too and I assumed it was related to the change @J-N-K outlines above. But what I can’t figure out is what I should be doing about it. for example, I’ve one Item that had two changes four seconds apart.

2023-06-29 09:40:01.604 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'JennsOfficeSensors_Humidity' changed from 40.8 % to 40.7 %                                                     
2023-06-29 09:40:05.641 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'JennsOfficeSensors_Humidity' changed from 40.7 % to 40.8 %                                                     │

This sensor reports once per second.

This generated the warning:

2023-06-29 09:40:02.590 [WARN ] [d4j.internal.RRD4jPersistenceService] - RRD4J does not support adding past value this=1688053200, last update=1688053201. Discarding JennsOfficeSensors_Humidity - 40.8

I am running on a pretty powerful machine (compared to an RPi) with a max system load of 1, plenty of RAM left with no swap and usually less than 50% of the CPUs active at any given time. There were no other events between the first change and the second change so it doesn’t seem like it should have taken three seconds to save the first record.

Those timestamps reported by the rrd4j warning do not make a lot of sense either.

If I understand it correctly and I’ve converted the epoch correctly, the first record was saved at 9:40:01 AM (1688053201 epoch) which tracks with when the event occurred.

But the next event didn’t occur until 09:40:05 AM (1688053205 epoch) but rrd4j thinks it occurred at 09:40:00 AM (1688053200 epoch)?

Something doesn’t add up. Where does the this=1688053200, last update=1688053201 come from? This doesn’t seem to map to the scenario @J-N-K outlined in post #342. These events occurred much farther apart than that.

I’ve been meaning to report this here and keep forgetting.

1 Like