Feed myget mongoose: 402 payment required

[guido.dalli]

Hi eveyone,

when I try to log in with VS2022 I get this error:

[SmartConnector] Il feed V2 nella 'https://www.myget.org/F/mongoose/auth/[mykey]/api/v2/Search()?$filter=IsLatestVersion&searchTerm=''&...' ha restituito un codice di stato '402 Payment Required' imprevisto.

Any idea?

[CraigEl · Accepted solution]

@guido.dalli It seems we were downgraded to free plan on MyGet. We need to get back on paid plan, but for now R&D is waiting on MyGet to process it.

[GreenieMax]

Any news about this issue? If things are working, should I use the same link or the link has changed?

[GreenieMax]

I'm still waiting and I do not see link for MyGet working, has the link changed, if so could you please give us the new link?

[SteveGregory]

@CraigEl any progress with this or is an alternative solution going to be available soon?

[ard]

Any updates on this issue?

[enzodino]

Any updates on this issue?

[enzodino]

Any updates on this issue?

[Mahmoud_Sayed]

There is a known issue topic: for this issue:SmartConnector: MyGet subscription is expired - Schneider Electric Community

[Erwin-vd-Zwart]

@Mahmoud_Sayed 

There is a new packet source via Github according to the latest release notes on smartconnectorserver.com (2.5.5.108), it works perfect but i see there are only packages for the latest version and also SmartConnector.Utilities.dll is missing.

Are there plans to add older versions to this Github packet source and will we add the extra libs like SmartConnector.Utilities.dll as it is an incredible usefull extention and used a lot in excisting developments..

[SteveGregory]

I agree, we need the older packages too.

[GreenieMax]

I personally think the whole idea of using a smart connector with a DLL that is compatible with C# .NET 4.8 is a bad idea, I think the best idea would be to have open MQTT protocol, which Smart Connector will understand and you could write the program in any language you like, the EXE Could be added to the webpage of smart connector, which will run it in the background.

It is an easy solution, there are lots of things .NET 4.8 doesn't support, and we would get rid of that problem, and add to that giving people the option to choose whatever language they want, the only thing Schneider Electric has to care about is the protocol, simple things like "create", "set", "get" and few other things could be sent as topic and other details could be sent in the JSON Payload.

[Erwin-vd-Zwart]

@GreenieMax 

I agree that the MQTT interface needs changes to be more open, R&D is aware of that but they have "higher" priorities that pushes these improvements further back on the roadmap. A few of these suggested improvements are JSON Path (with expressions) instead of point ID's and a trigger option to bind to a data group to be able to request a response on demand.

But MQTT is not a replacement for the SmartConnector Framework as it offers much more options for systems integrations that do not support the MQTT protocol.

There are plans to support Node Red on the next generation Automation Server 3, I have seen this running on L&B in Frankfurt and can't wait until that is brought to the system as it would require way less SmartConnector developments and the need of a "middleware server", there is no ETA for this and i keep my fingers crossed it will come in the near future.. 

[GreenieMax]

With all due respect sir, Node Red is a pain to work with for programmers, it is great for people who don't know programming but these same people have no idea about protocols and stuff, this is why programmers who know about protocols and communication exist.

Surely they know about Schneider Electric devices, but not how things work between two protocols.

The main idea is to send information to Smart Connector; whatever features exist will exist, and MQTT will only act like a pipeline to execute the required functionality.

Right now, I had to do it because we seriously had a problem connecting .NET 4.8 with Kafka, so we had to add an MQTT Broker in the middle, while Smart Connector works fine with MQTT and doesn't have required support for Kafka.

So we write our interfaces in Go, talking to MQTT Broker, which talks to a single Core DLL, which handles almost everything for us.

Even .NET 8 would be fine but we have serious problems with .NET 4.8 added to that are the libraries of Mongoose are all over the place, help really needed here.

[Erwin-vd-Zwart]

@GreenieMax 

I didn't say Node Red will solve everything, but for sure it will solve a huge part of nowadays "complex" integrations, especially to simple API's for energy prices, wheather conditions etc, in a simple way for everyone.

It also enables to host a MQTT broker, convert payloads to any format and offers a huge library of flows and you have the option to develop your own flow.

I welcome any extra option to make integrations on "device level" without the need of having a Windows based middleware server in between and yes there are always exceptions where there is a need for middleware like a SmartConnector..

[GreenieMax]

That would be good if we could do the integration on the device level; that will be a very positive move.

But on Device level it'll be a problem for a very large sites were we have 100s of controllers, that would complicate few things, but for smaller projects it is a great idea.

But it'll be great if we are given some programming language flexibility. Right now, I would really prefer something modern to be used for programming complex systems.

We made an interface for an FMS software, which works fine, but still would have helped if we used a faster framework.

So if you have any influence on Schneider Electric development directly, I would request you to tell them to use a Modern Framework, at least .NET 8 or 9.


Thank you for a great conversation,

[SteveGregory]

I'd like to see the SmartConnector framework converted to .net core and be able to host the software in an Automation Server. Then you would have the option of running on a server, controller or in docker.