CommandEntity and FormatEntity with asteval supports by renereimann · Pull Request #221 · project8/dragonfly

renereimann · 2025-05-28T06:24:56Z

We created two new endpoint entities

CmdEntity can execute a command, e.g. degaussing of a pressure gauge. This is differentent from get and set
FormatEntityAsteval which allows for a function to be defined in the config file that is used to convert the response (similar to calibration but more focussed on formating the response"

The Entities are used within the MATS setup for some time and seem to work fine.

…mand entity that we can use e.g. to degas our pressure gauges

renereimann · 2025-07-15T20:48:37Z

As discussed at yesterdays call here is a config file that uses both new implemented Entities:
https://github.com/project8/MainzDripline3/blob/main/Configurations/Devices/pressure_gauge_80_hpt200.yaml

nsoblath · 2025-07-18T21:08:45Z

+            set_value_map (str||dict): inverse of calibration to map raw set value to value sent; either a dictionary or an asteval-interpretable string
+            extract_raw_regex (str): regular expression search pattern applied to get return. Must be constructed with an extraction group keyed with the name "value_raw" (ie r'(?P<value_raw>)' ) 
+        '''
+        super().__init__(**kwargs)


We can't use super().__init__() because that mechanism doesn't work with the pybind11-wrapped code. You should directly call FormatEntity.__init__(). Once super() isn't used for part of the class hierarchy, we have to not use it elsewhere.

I fixed this

nsoblath · 2025-07-18T21:09:33Z

+                 **kwargs):
+        '''
+        Args:
+            get_str (str): sent verbatim in the event of on_get; if None, getting of endpoint is disabled


This list of arguments doesn't match what's in the __init__() function definition.

I added the additional asteval_str in the documentation. I still keep the other arguments since they are propergated via **kwargs and are needed by the baseclass

This seems like it invites version sheer between the docstring here and in FormatEntity - should maybe discuss convention.

nsoblath · 2025-07-18T21:13:08Z

+            logger.debug(f"matches are: {matches.groupdict()}")
+            result = matches.groupdict()['value_raw']
+
+        result = result.replace('\x00', '')


What's this line doing?

I removed it. This is not needed

nsoblath · 2025-07-18T21:13:52Z

+
+    @calibrate()
+    def on_get(self):
+        if self._get_str is None:


Should this block (lines 42-54) be replaced by a call to FormatEntity.on_get()?

Yes, I now use the FormatEntity.on_get function here

nsoblath · 2025-07-18T21:14:50Z

+__all__.append('CmdEntity')
+class CmdEntity(Entity):
+    def __init__(self, cmd_str=None, **kwargs):
+        Entity.__init__(self, **kwargs)


Class and init function need documentation

Added documentation

nsoblath · 2025-07-18T21:20:02Z

+        logger.debug("Command function was successfully called")
+        if self.cmd_str is None:
+            raise ThrowReply('service_error', f"endpoint '{self.name}' does not support cmd")
+        return self.service.send_to_device([self.cmd_str])


The call to Service.send_to_device() makes me think this is intended to be used with an EthernetSCPIService. That should be included in the documentation.

Added that this is for EthernetSCPIService

…s already defined in FormatEntity in init and on_get function.

…e to apply the asteval function to the dict value not the dict itself.

wcpettus · 2025-07-28T14:44:29Z

Two thoughts/questions on the CmdEntity related to this PR, but beyond the scope:

dripline cmd supports additional arguments, but the CmdEntity as written doesn't use them - if we get a device where it would be useful, could consider how best to flexibly incorporate the optional arguments (although I'm not thinking of an obvious application - since often you would just want a set there instead)
in the example config, you have an (empty) calibration - this isn't used here, right? (config file is not the PR, so no effect)

wcpettus

If I post a review, do my other comments go from "Pending" to be visible?

wcpettus · 2025-07-28T14:28:32Z

+
+    def cmd(self):
+        logger.debug("Command function was successfully called")
+        if self.cmd_str is None:


this placement feels odd - naively I would expect a CmdEntity which doesn't have a cmd_str provided to fail on init because it can't be useful (I would move this check to the init function and throw a ValueError if it's not provided, something like this https://github.com/driplineorg/dripline-python/blob/main/dripline/implementations/entity_endpoints.py#L41)
but maybe I'm missing an obvious use case

Good point, I moved it to the constructor.

wcpettus · 2025-07-28T14:48:02Z

+                 **kwargs):
+        '''
+        Args:
+            get_str (str): sent verbatim in the event of on_get; if None, getting of endpoint is disabled


This seems like it invites version sheer between the docstring here and in FormatEntity - should maybe discuss convention.

wcpettus · 2025-07-28T14:49:37Z

+
+
+__all__.append('CmdEntity')
+class CmdEntity(Entity):


May want a larger discussion on organization of the Entity "zoo" we are creating. The CmdEntity may be harder to find here in the same file as the Asteval one since they don't have an explicit relation (other than the same device needing both, but that subtlety will be lost on users of other systems)

I made a separate file for this. I agree that it should not go in the asteval_endpoint.py but we may easily end up with lots of files

wcpettus · 2025-07-28T14:52:40Z

+
+
+__all__.append('FormatEntityAsteval')
+class FormatEntityAsteval(FormatEntity):


May want a style guide for naming - typically the base class (Entity here) goes last
Does that make this a FormatAstevalEntity or an AstevalFormatEntity?

I changed to AstevalFormatEntity

…ormatEntityAsteval into AstevalFormatEntity, checking of input at constructor, improving doc strings

wcpettus

Looks good - we should keep an eye on CmdEntity, that may be worth elevating into dl-py codebase

wcpettus · 2026-01-22T20:04:58Z

@@ -0,0 +1,31 @@
+import re # used for FormatEntity
+
+from dripline.core import calibrate, ThrowReply


wcpettus · 2026-01-22T20:05:50Z

@@ -0,0 +1,31 @@
+import re # used for FormatEntity


wcpettus · 2026-01-22T20:07:56Z

@@ -0,0 +1,40 @@
+import asteval # used for FormatEntity
+import re # used for FormatEntity


asteval nor re used

wcpettus · 2026-01-22T20:08:47Z

+import asteval # used for FormatEntity
+import re # used for FormatEntity
+
+from dripline.core import calibrate, ThrowReply


ThrowReply not used

wcpettus · 2026-01-22T20:09:02Z

 ARG img_repo=dripline-python
-#ARG img_tag=develop-dev
-ARG img_tag=receiver-test
+ARG img_tag=v5.0.0-dev


added a FormatEntity that supports asteval, in addition define an com…

b83642d

…mand entity that we can use e.g. to degas our pressure gauges

renereimann requested a review from nsoblath May 28, 2025 06:25

renereimann requested a review from wcpettus July 17, 2025 06:14

merge develop into feature/asteval

5611674

nsoblath requested changes Jul 18, 2025

View reviewed changes

renereimann added 4 commits July 20, 2025 10:24

extending documentation of functions and classes, reusing code that i…

d8b8a41

…s already defined in FormatEntity in init and on_get function.

Fixing the dripline version in the docker compose file

8d1f7b2

fixing typo in name of super class

6ecb50a

we have to format the raw value, since its reported as a dict, we hav…

e2e23c1

…e to apply the asteval function to the dict value not the dict itself.

wcpettus requested changes Jul 28, 2025

View reviewed changes

separating cmd and asteval endpoints into different files, changing F…

656d2c5

…ormatEntityAsteval into AstevalFormatEntity, checking of input at constructor, improving doc strings

renereimann requested review from nsoblath and wcpettus October 6, 2025 16:39

nsoblath approved these changes Jan 22, 2026

View reviewed changes

wcpettus approved these changes Jan 22, 2026

View reviewed changes

wcpettus added 2 commits January 22, 2026 15:16

Merge branch 'origin/develop' into feature/asteval

7b699e8

Cleaning imports

ae59856

nsoblath merged commit 36045e8 into develop Jan 22, 2026
3 checks passed

renereimann deleted the feature/asteval branch January 23, 2026 08:09



		__all__.append('FormatEntityAsteval')
		class FormatEntityAsteval(FormatEntity):

		@@ -0,0 +1,31 @@
		import re # used for FormatEntity

		from dripline.core import calibrate, ThrowReply

		@@ -0,0 +1,40 @@
		import asteval # used for FormatEntity
		import re # used for FormatEntity

Conversation

renereimann commented May 28, 2025

Uh oh!

renereimann commented Jul 15, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

wcpettus commented Jul 28, 2025

Uh oh!

wcpettus left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

wcpettus left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants