Re: What should ProvidingManager.provide() return if not supported?


danielb987
 

LocoNet doesn't have support for analog values or string values as far as I know. So I'm going to use the LocoNet OPC_PEER command, using "SV programming format 1" and "SV programming format 2".

This means that an AnalogIO on the LocoNet needs:
* Destination address
* SV address
* Type (8 bit integer, 16 bit integer, 32 bit integer or 32 bit float)

A StringIO on the LocoNet needs:
* Destination address
* SV address
* Type (8 byte string using SV format 1 or variable length string using multiple OPC_PEER packages to send the string)

I can create a system name that has destination address, sv address and type, but I don't see the point of doing so since there is no way to auto discover analog IO or string IO on the LocoNet. I can discover OPC_PEER devices, but there is currently no way for the devices to tell their configuration of SV addresses.

My problem is not the need for a user name. My problem is that I need a destination address, sv address and type, and I prefer to not have these final to allow the user to be able to change these.

Daniel

2020-01-05 15:13 skrev Randall Wood via Groups.Io:

The requirement (and this is an *absolute* requirement) for NamedBeans
is that the user name is optional, and the system name is the only
name that’s needed.
User Names are set by the user, and only by the user, not by system
connections (unless the message in the system contains both something
that can be a system name and something that can be a user name).
This is because devices on a connection (like LocoNet) can *only* be
addressed by data encoded in the system name.
If you can’t work with that constraint then you don’t have a usable
design (especially for a device on the LocoNet).
Put another way, you can’t create a discovered LocoNet device with a
user name, because the LocoNet did not provide a user name to use,
just an address that is encoded into the system name.
ProvidingManagers are designed to work with system connected devices
to allow a flow like LocoNet traffic handler on connection “L”, sees
message from thing at address 42->reads message, determines thing is
Turnout->requests bean for turnout at address 42 (I.e. requests bean
LT42) be provided->ProvidingManager returns that bean, creating it if
needed.
If you *really* need to add LocoNet devices that can’t be provided
implement ProxyManager instead of extending AbstractProxyManager.
But I would first reconsider your requirement that user names be
assigned, since that’s not possible on the LocoNet itself.
Randall
On Jan 5, 2020, at 08:56, danielb987 <db123@...> wrote:
I'm implementing managers for AnalogIO and StringIO. I'm going to add a generic ProxyManager and a specific LocoNet manager for these.
AbstractProxyManager implements ProvidingManager, so I must add the method provide() in the ProxyManager. But I cannot create an AnalogIO or a StringIO from only a system name, so this method should always fail, at least for the LocoNet manager. What is the proper way to handle this? Throw an IllegalArgumentException("not supported") or throw an UnsupportedOperationException("not supported") ?
Daniel

Join jmri@jmri-developers.groups.io to automatically receive all group messages.