Best option to implement feature that requires additional libraries

[r-xyz]

Hello,
I have a couple of PR I wanted to work on since long time ago, and I might finally have time to dedicate.
One question before I get started. The main one would be adding support for a different class of interlocks (and maybe sensor), which would require additional python libraries.

What would be the best approach for it?

1. Make the PR against NIST and add requirement to install.py?
2. Make the PR against NIST, but use some kind of conditional import?
3. Make the PR against NEMO-CE, following one of the previous approaches
4. Make is as a separate app? (if so, where could I find a bit more of documentation to understand how to extend interlocks.py, leaving base classes available?

Thanks a lot in advance.

[rptmat57]

Hello,
My advice would be to make a separate app and add an interlocks.py file (rename the class and key to fit your situation):

from NEMO.interlocks import interlocks, Interlock
from NEMO.exceptions import InterlockError
from NEMO.models import Interlock as Interlock_model

class MyInterlockImplementation(Interlock):
    def _send_command(self, interlock: Interlock_model, command_type: Interlock_model.State) -> Interlock_model.State:
        # add your implementation
        pass

interlocks["my_implementation"] = MyInterlockImplementation()

you can also implement the clean_interlock_card and clean_interlock if you need.

You'll also need to create the apps.py file with the following:

from django.apps import AppConfig

class MyPluginConfig(AppConfig):
	name = "NEMO_my_plugin"
	default_auto_field = "django.db.models.AutoField"

	def ready(self):
		from NEMO_my_plugin import interlocks # unused but required import

Now, to use your app, you'll need to add it in INSTALLED_APPS (before NEMO) and go into detailed administration and add a new interlock card type with the matching keymy_implementation

That should be all.

[rptmat57]

when you move it completely out of NEMO, you'll be able to remove the NEMO.apps. part of it.
you will also need to fix imports when you move it out, by removing NEMO.apps.` from the import statements.

[r-xyz]

oh, I see, thank you very much for the help! :)
With that, I already got started and got basic functionality working. To get full functionality, I will need some extra fields in the Interlock configuration (I need strings, otherwise I could have reused the existing as workaround).
I was thinking of modifying the admin view, similar to NEMO userdetails, unless there are any similar changes planned in this direction.

[OT]
PS: I wanted to update one thing on the wiki I had an issue with, but I was not sure if I made anything wrong or it really needs an update. I take the chance to comment, since maybe open a bug report for the wiki might be overkill:

• Under 'Initialize NEMO', I had to run python manage.py ... commands from the main NEMO folder, not from NEMO\NEMO as it appear to be suggested. Maybe manage.py moved over the history of the project or did I miss something else?
• To compensate for the previous change, under 'Create settings for NEMO', I had to create the settings file under the main NEMO folder, not NEMO/NEMO and modify BASE_DIR = os.path.dirname(os.path.dirname(os.path.abspath(__file__))) to BASE_DIR = os.path.dirname(os.path.abspath(__file__))

[/OT]

[rptmat57]

I see 2 options:

1. Do what NEMO-user-details is doing, but just be aware that this approach doesn't scale. meaning if another plugin wants to also add fields to interlock configuration and modify the admin view, it'll need to check if your plugin is installed to not interfere with your admin override.
2. Another way is to simply add a new model which extends the current interlock model (or has a OneToOne link to it), and have your own admin view for your new interlock type. It's a bit more annoying to have to go to 2 separate models for interlocks, but that approach keeps things separate. In the interlock implementation you'll be able to check if the OneToOne exist (use hasattr or getattr otherwise it'll break if the relationship doesn't exists) and use it to send commands.

Thanks for fixing that on the wiki! Indeed, manage.py got moved to the top level folder a while back and I forgot to update the paths.

[r-xyz]

Thanks Mathieu,
I am going for # 2, since I understand it will have less drawbacks in the long-run.
I managed to create the OneToOne relationship and have my own view. As far as I understand, the only workflow possible would be to add first a normal "InterlockCard" and "Interlock" and then define the correspondent new classes, selecting the base object:

One last question:
Currently the Interlock Admin view shows columns indicating the tools connected: is there a way I can add something similar to my admin view? Or at least a way I can show in the view attributes from the main class "Interlock"?

PS: I updated the wiki and also added black installation.

[r-xyz]

Almost done. 🎆 The code is working well, I just need to finish a few details/cleanups (e.g. see how to package it).
As soon as I have it I will publish the first beta; I would really appreciate if you could have a look and share feedback whenever you have a moment.
I was also thinking of a one potential improvement of the current interlocks model which could improve usability of this and future similar expansions. Once I shared the code, I would like to discuss it with you to verify it does not have any drawbacks.

[rptmat57]

I believe you should be able to extend the Interlock model, and have your admin view include all the fields. It will automatically add it to the regular Interlock model. You can then leave them there, or override the regular interlock admin and filter to only who the regular ones and not your new model.
You can take a look at the contracts internal plugin. Specifically Procurement and ServiceContract models, which might give you some pointers.

with regards to showing related attribute, you have to use the following in admin.py (assuming your OneToOne is name "interlock"):

list_display = ["get_interlock_card"]

@display(boolean=True, ordering="interlock__interlock_card__name", description="Interlock Card")
    def get_interlock_card(self, obj):
        return obj.interlock.interlock_card.name

[rptmat57]

For packaging, you'll have to extract it, fix the imports, create your setup.py, and push to pypi.
If you'd like to host the code on gitlab, I can create a new subgroup for you in https://gitlab.com/nemo-community/. totally up to you.
I suggest you take a look at the other plugins in https://gitlab.com/nemo-community/atlantis-labs, particularly the setup.py, setup.cfg, MANIFEST.in and gitlab-ci.yml files.

Let me know if you have any other questions.

[rptmat57]

Hi,
Thanks, you can check this out for Pypi release if you are having trouble:
https://gitlab.com/nemo-community/nemo-ce/-/blob/master/.gitlab-ci.yml?ref_type=heads#L66

[rptmat57]

Make sure to include the migration file, they are checked in for some reason

[r-xyz]

I am happy to share that I just published my NEMO plugin: NEMO-mqtt.
The plugin adds the possibility to control MQTT interlocks. I think this could be a useful option for labs or environments where MQTT backend is used (and TCPModbus is not an option due to security requirements).
First beta release (0.3.2) is on PyPI, too.
Whenever you have time I would appreciate if you have any feedback.
In particular, I have a few comments/doubts.

1. I "extended" Interlock and InterlockClass models only by creating a One-To-One connection. I am not sure if I should have define the new models as extension of the Interlock/InterlockClass models (instead of BaseModel).

   class MqttInterlock(BaseModel):
     [...]
     interlock = models.OneToOneField(Interlock, on_delete=models.CASCADE)
     [...]

2. Probably because of the above, or something else I am missing, I have trouble to add attribute from the related interlock class to MqttInterlockAdmin page. For example, if I try to add a get_interlock_most_recent_reply column with:

   @admin.display(boolean=True, ordering="interlock__most_recent_reply", description="Interlock Card")
   def get_interlock_most_recent_reply(self, obj):
       return obj.interlock.most_recent_reply

   I get a KeyError exception as shown below.
   

3. [Optional improvement]:Currently Interlock objects have no name/label: their name is determined as something like InterlockCardName:host, channel#. Having names/labels would help discriminate between them in this case. Also, the current model allows creating non-unique names (if you define multiple Interlocks on the same card, leaving non-mandatory fields empty).

Thanks again for all the help.

[r-xyz]

Make sure to include the migration file, they are checked in for some reason

Thanks, somehow I missed it.
Uploaded and rebuilding version 3.3.3

[rptmat57]

just remove the boolean=True

[rptmat57]

Congratulations on your first plugin! that was fast!

[rptmat57]

One more suggestion, you could consider adding a migration that creates the interlock card category automatically.
It would check first if there is already one with the same key, and if not add it.
something like:

    def set_mqtt_interlock_category_forward(apps, schema_editor):
        InterlockCardCategory = apps.get_model("NEMO", "InterlockCardCategory")
        InterlockCardCategory.objects.get_or_create(name="MQTT", key="mqtt_interlock")

    def set_mqtt_interlock_category_reverse(apps, schema_editor):
        pass

    migrations = [
        migrations.RunPython(set_mqtt_interlock_category_forward, set_mqtt_interlock_category_reverse),
    ]